Re: [swift-evolution] [pitch] adding toggle to Bool

+1 for toggle, seems the clear winner for me. > On Jan 12, 2018, at 8:29 AM, Cheyo Jimenez via swift-evolution > wrote: > > It’s a slippery slope because it makes me want to have something like `not()` > added to the library. I don’t think it’s worth it. > I would love to have not(), but fo

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

Big +1 to this. Getting these types out of the standard library and into a more suitable domain-specific framework, prior to declaring ABI Stability, will give us flexibility to evolve them appropriately over time. > On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution > wrote: > > G

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 9, 2018, at 11:48 AM, Chris Lattner wrote: > >> On Jan 9, 2018, at 10:23 AM, Ben Cohen wrote: The old name can live on indefinitely via a typealias (which has no ABI consequences, so could be retired at a later date once everyone has had plenty of time to addres

Re: [swift-evolution] [Proposal] Random Unification

> On Jan 9, 2018, at 2:12 AM, Jonathan Hull via swift-evolution > wrote: > > - Why bother supporting non-closed Ranges at all? If you only allow closed > ranges, then you can’t end up with an empty range. The only difference in > behavior I can think of is on floating point, but I can’t thi

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 8, 2018, at 10:12 PM, Chris Lattner wrote: > > >> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> There exists in the standard library a type `DictionaryLiteral` that >> deserves naming

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 8, 2018, at 5:08 PM, Karl Wagner wrote: > > > >> On 9. Jan 2018, at 01:29, Ben Cohen via swift-evolution >> wrote: >> >> There exists in the standard library a type `DictionaryLiteral` that >> deserves naming re-consideration before

[swift-evolution] 100% bikeshed topic: DictionaryLiteral

There exists in the standard library a type `DictionaryLiteral` that deserves naming re-consideration before we declare ABI Stability, because it’s confusingly misnamed, being neither a Dictionary (it doesn’t provide key-based lookup of values) nor a Literal. Instead, it’s just an immutable co

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

ndorsed but then realized this edge case changed matters to rescind their endorsement. > - Karl > >> On 4. Dec 2017, at 19:39, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> They will continue to conform to Collection just

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

They will continue to conform to Collection just as they do today. Range.IndexDistance is already an Int. > On Dec 4, 2017, at 10:35, Karl Wagner via swift-evolution > wrote: > > What does this mean for ranges of integers, as Xiaodi mentioned in the review > thread? Can they still conform to

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

t we are all clear on the implications of this, if IndexDistance > becomes Int, ranges of integers will stop conforming to Collection, because > Int.min.. potentially many more. > > This would entail nontrivial source breakage. > > > On Mon, Nov 27, 2017 at 22

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

My suggestion would be: don’t have your Collection-like type conform to Collection. Give it collection-like methods if you want them, like an indexing and slicing subscript that takes an Int64. It can still conform to Sequence. In practice, these “huge” collections will be mostly used concretely

[swift-evolution] [Accepted]

Hello Swift Community, The review of of “SE-0188: Make stdlib index types Hashable” ran from November 8th to 14th, 2017. This proposal has been accepted. During the review, the only point of discussion was whether to go one step further and make conformance to Hashable a requirement for all Col

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

I continue to favour mapSome, since it’s both literally and figuratively what it does, but appreciate that exposing the name of the Optional.some case isn’t to everyone’s taste. > On Nov 15, 2017, at 12:55 PM, John McCall via swift-evolution > wrote: > > Hello, Swift Community! > > The initi

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 10, 2017, at 4:07 AM, Tino Heth <2...@gmx.de> wrote: > > >> The “think of optionals as collections” explanation is a good way to help >> people who are confused by the overload. But an even better way would be to >> not have a confusing overload in the first place. > With the renamin

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 9, 2017, at 4:01 PM, Paul Cantrell wrote: > > using the same name for both flatMap variants causes the type checker to > miss programmer errors Not to mention, makes it do a lot more work, lengthening compile times (especially when mixed with closure and literal type inference… the

Re: [swift-evolution] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 9, 2017, at 11:43 AM, Vladimir.S via swift-evolution > wrote: > > let a : [Int?] = [1,2,3,nil,4,nil,5] > > let b = a.flatMap { $0.flatMap{$0*10} } // current At the risk of taking us further down the rabbit hole… You really want: let b = a.flatMap { $0.map{$0*10} } // current

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution > wrote: > > On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> >> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote: >>> The problem in the Doodads

[swift-evolution] [Review] SE-188 Make stdlib index types Hashable

Hello, Swift community! The review of “SE-0188: Make stdlib index types Hashable” begins now and runs through November 14th, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 3:35 PM, Kevin Ballard via swift-evolution > wrote: > > It's a fairly minor issue, one that really only affects new Swift programmers > anyway rather than all users > I’ve seen enough misuse of flatMap at this point to be confident saying it’s not just a beginner erro

Re: [swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

> On Nov 8, 2017, at 1:55 PM, Ben Cohen wrote: > > Apologies to Nate Cook, from whom this important came. I would love to pretend my accidentally a word there was a joke. But it wasn’t… ___ swift-evolution mailing list swift-evolution@swift.org htt

Re: [swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

> On Nov 8, 2017, at 1:37 PM, Ben Cohen via swift-evolution > wrote: > > This turns any problem of writing a generic collection algorithm into both a > collection _and_ > problem. Gah, typo. That should read “This turns any problem of writing a generic collection alg

[swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

Hi Swift Evolution, A pitch for review, aimed at simplifying generic Collection algorithms. Online copy here: https://github.com/airspeedswift/swift-evolution/blob/5d1ffda2e83f5b95a88d5ce3948c5fd0d59622f4/proposals/-eliminate-indexdistance.md

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 18, 2017, at 5:28 AM, Ole Begemann via swift-evolution > wrote: > > It also seems to clash with Michael's idea > > that two substitutable sequences should return true for ==. This is a bug in Float

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

> On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution > wrote: > > there is no way to allow one-sided subscripting, but disallow two-sided > subscripting for the memory API One-sided subscripting is just shorthand for “from here to the end” (or from the start to/through here). If a o

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 4, 2017, at 19:26, Xiaodi Wu via swift-evolution > wrote: > > extension Data { > static func random(byteCount: Int) -> Data > } > Instead of methods on specific concrete types, I’d prefer to have a Sequence or Collection-conforming type that you could compose with existing opera

Re: [swift-evolution] [Proposal] Random Unification

ese static functions from numeric types. >>> >>> - Alejandro >>> >>> El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution >>> mailto:swift-evolution@swift.org>> escribió: >>> >>>>> On Oct 5, 2017, at 11:30 AM, Ben

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution > wrote: > >> ``` >> extension Int { >> static func random(in range: Countable{Closed}Range) -> Int >> } > > Nice. Should these be initializers like: > > extension Int { > init(randomIn: Countable{Closed}Range) > } > I do

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution > wrote: > > If trapping is OK, then surely returning Optional is superior; any user who > is OK with trapping can make that decision for themselves by writing > `random()!`. Everyone else can then see clearly that trapping is a >

Re: [swift-evolution] [Proposal] Random Unification

> On Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution > wrote: > > >> On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon > > wrote: >> >>> On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 29, 2017, at 1:23 PM, Taylor Swift wrote: > > I think this is a reasonable argument and convinced myself that it's possible > to extend the slice API. I'm also convinced now that we don't need overloads > to handle an UnsafeBufferPointer source, instead we can provide a single > gen

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

> On Sep 27, 2017, at 12:44 PM, Tony Allevato wrote: > > > > On Wed, Sep 27, 2017 at 10:36 AM Ben Cohen via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > >> On Sep 25, 2017, at 2:12 AM, Alwyn Concessao via swift-evolution >>

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

> On Sep 25, 2017, at 2:12 AM, Alwyn Concessao via swift-evolution > wrote: > > mutating func removeElementInSubrange(_ elementToBeRemoved:Element,in > range:Range){ > > //check if elementoBeRemoved exists; if yes, check if the index of > elementToBeRemoved is part of the subrange, if yes t

Re: [swift-evolution] Re-pitch: remove(where:)

And here are my answers, in a separate email to maintain a shred of separation between objectivity and subjectivity :) > On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution > wrote: > > 1. Is it right to assert that with a “removing” operation, the closure should > re

[swift-evolution] Re-pitch: remove(where:)

Hi everyone, Reviving a pitch for a feature that didn’t make it into Swift 4. This was discussed in the core team recently, and feedback was wanted regarding the naming of the method and the polarity of the where closure. Here’s the proposal: https://github.com/airspeedswift/swift-evolution/b

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

> On Sep 26, 2017, at 2:59 AM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Sep 26, 2017 at 00:15 Jonathan Hull > wrote: > As he says, it is an in-place equivalent of filter, so the use-cases would be > similar. I could see this being extremely useful. Off the

Re: [swift-evolution] [Proposal] Random Unification

Hi Alejandro, I’m really happy to see someone pick this up. We had suggested some kind of random support could be a goal for addition to the standard library in Swift 4 phase 2 but didn’t manage it, so I definitely think a good proposal would be given consideration for Swift 5. Regarding the i

Re: [swift-evolution] Draft: Regular Expression in Swift

Hi Joshua, Thanks for bringing this topic up. It may help to outline why regular expressions were deferred until Swift 5. The work to create a regular expression type itself, and even to add a regex literal protocol, is fairly straightforward and probably could have been done in the Swift 4 ti

[swift-evolution] Revision review: SE-104: Protocol-oriented integers

Hi Swift community, Following feedback during the 4.0 preview, a handful of minor amendments have been suggested to SE-104: Protocol-oriented integers that the core team feels are important to include into 4.0 as they have an impact on source stability. The review of this amendment begins now a

Re: [swift-evolution] [Proposal] Refine SE-0015 (Tuple Comparison Operators) to include empty case

Hi Arjun, Thanks for picking up this Jira. The core team discussed this today and we think it’s OK to consider this a minor amendment to the original proposal and go ahead with the change without needing a further review. Cheers, Ben > On Jul 10, 2017, at 8:35 AM, Arjun Nayini via swift-evolut

Re: [swift-evolution] [pitch] Substring performance affordances

> On Jun 28, 2017, at 10:26 AM, rintaro ishizaki wrote: > > Does this mean it's guaranteed that Substring.hashValue is always equal to > String.hashValue? Yes. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailm

Re: [swift-evolution] [pitch] Substring performance affordances

> On Jun 28, 2017, at 2:41 PM, David Hart wrote: > > Should authors use StringProtocol or String as often as possible? Our general advice is to stick with String. Most APIs would be simpler and clearer just using String rather than being made generic (which itself can come at a cost), and us

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 6:32 PM, Xiaodi Wu wrote: > > the reason why a function would return nil _are intended to be obvious, per > the design rationale given in Swift project documents_. The reason .last returns nil is obvious. But it doesn’t tell you anything about why the array itself shoul

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution > wrote: > > In the initial example, repeated here in largely identical form, the desired > comment is "array must be non-empty." In what way does that provide more > information than a bare `!`? > By the same token, why does prec

[swift-evolution] [pitch] Substring performance affordances

Hi swift-evolution, Below is a short pitch for some performance improvements to be made to String to accommodate Substrings. As outlined in SE-0163, the more general question of implicit conversion from Substring to String was deferred pending feedback on the initial implementation. To date,

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution > wrote: > > Count me in as a strong proponent of ?? () -> Never. We don't need to burden > the language with an extra operator just for that. You could say the same about ?? The concern that an additional operator (and one that,

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 6:03 AM, Erica Sadun via swift-evolution > wrote: > > In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can > argue both ways, with the goal in reading code as "unwrap or die". > Personally, I strongly prefer `foo !! "explanation"` over `foo ??

Re: [swift-evolution] Passing functions with default parameters

Hi Oskar, This is actually something we’ve spoken about in the core team meetings in the past as a known thing that ideally would work but doesn’t. The one that hits me a often is that I wish .forEach(print) worked, as it’s very useful as a quick debugging command. I don’t know if we’re tracki

Re: [swift-evolution] Int indexing into UTF16View

> On Jun 8, 2017, at 10:32 AM, David Hart via swift-evolution > wrote: > > Hello, > > When working with Strings which are known to be ASCII, I tend to use the > UTF16View for the performance of random access. I would also like to have the > convenience of indexing with Int: > > let barcode

Re: [swift-evolution] Revisiting SE-0110

I very much agree with your concerns about this change in general. On this specific example, though, I just wanted to point out that there doesn’t seem to be a good reason to use .forEach here. for (key, value) in self { // etc } Would work perfectly well and is clearer IMO, still works with

[swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

Hello Swift community, The review of revisions to SE-0176: Enforce Exclusive Access to Memory begins now and runs through May 17, 2017. Most of this proposal was previously accepted. An implementation issue has been discovered with the use of dynamic enforcement on inout parameters. The prop

[swift-evolution] [Accepted pending revision review] SE-0176 Enforce Exclusive Access to Memory

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md The review of SE-0176 "Enforce Exclusive Access to Memory" ran fro

Re: [swift-evolution] [pitch] Character.unicodeScalars

> On May 10, 2017, at 11:13 PM, Brent Royal-Gordon > wrote: > >> On May 10, 2017, at 4:51 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Add a unicodeScalars property to Character, presending a lazy view of the >

[swift-evolution] [pitch] Character.unicodeScalars

Hi swift-evolution, A short string-related pitch for you. Add unicodeScalars property to Character Proposal: SE- Authors: Ben Cohen Review Manager: TBD Status: Awaiting review Introduction This proposal adds a unicodeScalar view to Character, similar t

Re: [swift-evolution] [Pitch] Enumerate from offset

I agree we shouldn’t have both, that would cause confusion/bloat. The downside I see of making zip a method on Sequence is that the first argument is not somehow more “special” than the second. Were it not for the chaining (and discoverability) issue, I’d be against it – it feels right as a free

Re: [swift-evolution] [Pitch] Enumerate from offset

> On May 4, 2017, at 10:15 AM, Jaden Geller via swift-evolution > wrote: > > It's been suggested by a core team member that enumerated itself might not > hold its weight in the standard library. Instead, we ought to write > `zip(foo.indices, foo)` or `zip(0..., foo)`. It's easier for the call

[swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

Hello Swift community, The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and runs through May 8, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md

[swift-evolution] [Accepted] SE-0170: NSNumber bridging and Numeric types

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md The review of SE-0170 “NSNumber bridging and Numeric types” ran from April 14 to April 21, 2017. The proposal is accepted for Swift 4. Thanks to everyone who participated! Ben Review Manager

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0173: Add `MutableCollection.swap(_:with:)

> On Apr 26, 2017, at 9:12 PM, John McCall via swift-evolution > wrote: > >> >> Is that a mistake? Wouldn't the free function forward to the added method? > > I'm not sure why this is there. The implementation of the method is not part > of the library specification. If it forwards to the

Re: [swift-evolution] [Review] SE-0173: Add `MutableCollection.swap(_:with:)

Hi everyone, Regarding the naming of the method: we discussed this amongst the core team and the feeling is that elements.swapAt(i, j) is the appropriate choice. We have a specific exception in the API naming guidelines around a preposition at the end of a base name, when the preposition applie

Re: [swift-evolution] [Accepted] SE-0171: Reduce with inout

:head-desk emoji: The one in the subject-line. SE-0171: Reduce with inout. Thanks for the spot, sorry about that. > On Apr 24, 2017, at 4:46 PM, Xiaodi Wu wrote: > > ...um, which proposal is being accepted? > > On Mon, Apr 24, 2017 at 6:31 PM, Ben Cohen via swift-evolution

[swift-evolution] [Accepted] SE-0171: Reduce with inout

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md Hello Swift Community, The review of SE-0171 "Remove final support in protocol extensions” ran fro

Re: [swift-evolution] [pitch] Change filter to return an associated type

> On Apr 23, 2017, at 1:30 PM, Xiaodi Wu wrote: > > On Sun, Apr 23, 2017 at 3:12 PM, Ben Cohen > wrote: > >> On Apr 23, 2017, at 1:05 PM, Xiaodi Wu > > wrote: >> >> Is it the intention that `associatedtype Filtered : Sequence` once recur

Re: [swift-evolution] [pitch] Change filter to return an associated type

returns a Sequence. > > On Sun, Apr 23, 2017 at 2:37 PM, Ben Cohen via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > Hi swift evolution, > > The following is a proposal that came off the back of the discussions > accepting the recent Dictionary pr

[swift-evolution] [pitch] Change filter to return an associated type

Hi swift evolution, The following is a proposal that came off the back of the discussions accepting the recent Dictionary proposal. It is small but has source-breaking implications so would be good to get in for the 4.0 release. Online copy here: https://github.com/airspeedswift/swift-evolut

[swift-evolution] Add MutableCollection.swap

Hi Swift community, Another pitch, this time related to the ownership manifesto. Add MutableCollection.swap(_:with:) Proposal: SE- Authors: Ben Cohen Review Manager: TBD Status: Awaiting review Introduction As part of the introduction of the Law of Exclu

[swift-evolution] [Accepted] SE-165: Dictionary & Set Enhancements

Hello Swift Community, The review of SE-165: Dictionary & Set Enhancements ran from April 6...11, 2017. The proposal is accepted with some revisions regarding naming: 1) The key/value sequence of init that does not take a closure resolving key conflicts will be named init(uniqueKeysWithValues:)

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution > wrote: > > >> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> For example, I expect `XCTAssertEqual(_:_:)` to b

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

Apologies, if you are reading this in HTML the links appear to be pointing to the incorrect proposal. Here is the corrected link: https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md > On Apr 14, 2017, at 11:30 AM, Ben Cohen wrote: > > Hello Swift community,

Re: [swift-evolution] [swift-evolution-announce] SE-0171: Reduce with inout

Apologies, if you are reading this in HTML the links appear to be pointing to the incorrect proposal. Here is the corrected link: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md > On Apr 14, 2017, at 11:37 AM, Ben Cohen wrote: > > Hello Swift communit

[swift-evolution] SE-0171: Reduce with inout

Hello Swift community, The review of “SE-0171: Reduce with inout" begins now and runs through the Friday after next, April 14th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

[swift-evolution] SE-0170: NSNumber bridging and Numeric types

Hello Swift community, The review of “SE-0170: NSNumber bridging and Numeric types" begins now and runs through the Friday after next, April 14th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md

Re: [swift-evolution] [pitch] Comparison Reform

Online copy here: https://github.com/airspeedswift/swift-evolution/blob/fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/-ComparisonReform.md > On Apr 13, 2017, at 1:17 PM, Ben Cohen via swift-evolution > wrote: > > > Hi swift evolution, > > Here’s another pit

[swift-evolution] [pitch] Comparison Reform

Hi swift evolution, Here’s another pitch, for The Propoosal Formerly Known As Spaceship. Comparison Reform Proposal: SE- Authors: Robert Widmann , Jaden Geller , Harlan Haskins , Alexis Beingessn

[swift-evolution] [pitch] One-sided Ranges

Hi Swift community, Another proposal pitch. These operators were mentioned briefly in the String manifesto as prefixing/suffixing is very common with strings. Online copy here: https://github.com/airspeedswift/swift-evolution/blob/71b819d30676c44234bac1aa61fc5c39bcf3/proposals/-OneSided

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

> On Apr 8, 2017, at 5:41 PM, Brent Royal-Gordon wrote: > >> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> +1. Perfect. Let's not bikeshed this and get it done! > > > Sorry, I'm going to have to insist on bikeshedding. > > `equ

[swift-evolution] [pitch] Adding in-place removeAll to the std lib

Hi swift-evolution, Another short proposal related to the Collection algorithms theme, this time for removing elements in-place from a collection. Online copy here: https://github.com/airspeedswift/swift-evolution/blob/1aac5593828941431d1805503865e7a2913d538b/proposals/-RemoveWhere.md A

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 6, 2017, at 12:35 PM, Joe Groff via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/propo

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

> On Apr 5, 2017, at 10:32 PM, Félix Cloutier wrote: > > During the proposal phase, we asked how this would handle fixed-length > strings with an optional NUL terminator. For instance, in a C `struct Foo { > char name[8]; };`, `name` stops at the first \0, or at the eighth byte, > whichever c

[swift-evolution] SE-165: Dictionary & Set Enhancements

Hello, Swift community! The review of "SE-165: Dictionary & Set Enhancements" begins now and runs through next Tuesday, April 11th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 31, 2017, at 2:00 AM, Brent Royal-Gordon > wrote: > >> On Mar 30, 2017, at 2:42 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> (or rather, given substrings will be 2-3 words, the not-even-that-small >&

Re: [swift-evolution] [Pitch] String revision proposal #1

Hi Brent, Sorry, I realized I failed to reply to these at the time. See below. > On Mar 30, 2017, at 6:52 PM, Brent Royal-Gordon > wrote: > >> On Mar 30, 2017, at 2:36 PM, Ben Cohen > > wrote: >> >> The big win for Unicode is it is short. We want to encourage peopl

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> On Mar 31, 2017, at 4:20 PM, Robert Bennett via swift-evolution > wrote: > > Sorry, despite the curt tone of my initial post, I think this is overall a > great idea. Ben, thanks for drafting the proposal. > No worries! >> On Mar 31, 2017, at 6:12 PM, Ricardo Parada wrote: >> >> I agree.

[swift-evolution] [Pitch] Add an all algorithm to Sequence

Hi, A short proposal for you as part of the algorithms theme. Hopefully non-controversial, aside from the naming of the method and arguments, about which controversy abounds. Online copy here: https://github.com/airspeedswift/swift-evolution/blob/9a778e904c9be8a3692edd19bb757b23c54aacbe/proposa

Re: [swift-evolution] [Pitch] String revision proposal #1

://stackoverflow.com/a/27456220/251153> >>> is that you take a pointer to the CChar tuple that represents the >>> fixed-size array, but this still requires the string to be NUL-terminated. >>> What do we think of an additional init(cString:) overload that takes an

Re: [swift-evolution] [Pitch] String revision proposal #1

erminated. What do we >> think of an additional init(cString:) overload that takes an >> UnsafeBufferPointer and reads up to the first NUL or the end of the buffer, >> whichever comes first? >> >>> Le 30 mars 2017 à 02:48, Brent Royal-Gordon via swift-evolutio

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 10:05 AM, Karim Nassar via swift-evolution > wrote: > > >> Message: 12 >> Date: Thu, 30 Mar 2017 12:23:13 +0200 >> From: Adrian Zubarev >> To: Ben Cohen >> Cc: swift-evolution@swift.org >> Subject: Re: [swift-evolution] [Pitch] String revision proposal #1 >> Message-ID:

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 2:03 PM, Karl Wagner via swift-evolution > wrote: > > So, running with the parallel, why not add a conditional conformance: "Slice: > Unicode where Base: Unicode”? > Primarily because this would rule out giving substrings the “small string optimization" where we pack t

Re: [swift-evolution] [Pitch] String revision proposal #1

Hi Brent, Thanks for the notes. Replies inline. > On Mar 30, 2017, at 2:48 AM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 5:32 PM, Ben Cohen via swift-evolution >> wrote: >> >> Hi Swift Evolution, >> >> Below is a pitch for the fir

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 11:20 AM, Brent Royal-Gordon > wrote: > > (That's why there's no adjective form of "string", which makes naming the > protocol difficult.) We-eelll, there is “Stringy”…. As tempting as it is to call the protocol this, it’s probably not a good idea. (then again, if we c

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 8:59 AM, Adrian Zubarev via swift-evolution > wrote: > > We cannot rename SubSequence to Subsequence, because that would be odd > compared to all other types containing Sequence. > > There is a difference between subsequence, which is one word, and the others, which ar

Re: [swift-evolution] [Pitch] String revision proposal #1

Result? > I think Parse. As in, this is the result of a parse, not these are the parsed results (though it does contain parsed results in some cases, but not all). > > On Wed, Mar 29, 2017 at 19:32 Ben Cohen via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >

[swift-evolution] [Pitch] String revision proposal #1

Hi Swift Evolution, Below is a pitch for the first part of the String revision. This covers a number of changes that would allow the basic internals to be overhauled. Online version here: https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/01

Re: [swift-evolution] Revisiting 'T != Type' in where clause

> On Mar 17, 2017, at 3:27 AM, Slava Pestov via swift-evolution > wrote: > > Overload resolution has a lot of heuristics, but it’s not magic. It simply > doesn’t know how to handle this case. > I think this might this just be a bug in overload resolution that’s since been fixed... ToT compi

Re: [swift-evolution] Pitch: Range return values for String Insert/Replace methods

Hi Charles, As part of the String redesign in Swift 4, these methods on String are intended to be part of String’s conformance to RangeReplaceableCollection. As such, this proposal should be phrased in terms of a change to that protocol, rather than to String. Couple of additional things to no

Re: [swift-evolution] Infer types of default function parameters

> On Mar 11, 2017, at 1:17 PM, Jaden Geller via swift-evolution > wrote: > > > > On Mar 11, 2017, at 12:20 PM, David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> >>> On Mar 11, 2017, at 12:57 AM, Jean-Daniel via swift-evolution >>> mailto:swift-evolution@sw

Re: [swift-evolution] Additive proposals

Hi Adrian, Thanks for bringing this up. We discussed this amongst the core team and have the following guidance that may help. It’s worth noting that some additive proposals are currently in scope, where they are aligned with the themes set out for Swift 4. For example, additive proposals for

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Hi everyone, The core team met and reviewed the discussion of this proposal so far, and had the following mid-review feedback to relay back to the list: Regarding the “Number” protocol: it was felt this is likely to cause confusion with NSNumber, given the NS-prefix-dropping versions of other F

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Hi everyone, The core team met and reviewed the discussion of this proposal so far, and had the following mid-review feedback to relay back to the list: Regarding the “Number” protocol: it was felt this is likely to cause confusion with NSNumber, given the NS-prefix-dropping versions of other F

Re: [swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

> On Feb 22, 2017, at 10:42 AM, Nate Cook via swift-evolution > wrote: > > Oops, left out that there's this horrifying way of writing it right now: > > extension Collection { > func index(_ i: Index! = nil, offsetBy n: IndexDistance) -> Index { > let i = i ?? startIndex > /

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

There is another option to avoid the extra types, which is to stop trying to force the disambiguation through argument labels, accept an ambiguous call and have the context disambiguate: // compilation error: ambiguous let x = i.multiplied(by: j) // unambiguously overflow-checked let (y,overflow

  1   2   >