Re: [swift-evolution] Swift 5: start your engines

The project would definitely be well-served by having more documentation, and hopefully we’ll see that grow both incrementally and in spurts. Even writing tutorials, however, must be weighed against competing priorities — such as finishing the work for ABI stability. My hope is we can find a b

Re: [swift-evolution] Swift 5: start your engines

Async / await is really spoiling me in Node.JS at the moment, you leave with shiver with anticipation!!! :) Sent from my iPhone > On 9 Aug 2017, at 06:41, Chris Lattner via swift-evolution > wrote: > > >> On Aug 8, 2017, at 8:19 PM, Susan Cheng via swift-evolution >> wrote: >> >> is it ac

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 11:10 PM, Taylor Swift wrote: > > > On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick > wrote: > >> On Aug 8, 2017, at 8:44 PM, Taylor Swift > > wrote: >> >> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I

Re: [swift-evolution] Swift 5: start your engines

> On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution > wrote: > > Upfront costs *will* be higher. Not only do you have to believe that a change > is good, you must develop a working group that includes coders to create a > prototype without any guarantee that the change will pass must

Re: [swift-evolution] Swift 5: start your engines

Would it be possible to get a series of tutorials on how the systems that make up Swift generally work? In other words, what are the pieces and how do they fit together? I think it would be useful even for people who aren’t directly implementing because they can have a better idea of how diffi

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

The benefit that standard library containers have over containers from other modules is that they're optimized as if they were part of your own module, so you can get the same thing by including the collection classes in your own executable instead of linking with the module. It's my understandi

Re: [swift-evolution] Swift 5: start your engines

> Le 9 août 2017 à 00:06, Erica Sadun via swift-evolution > a écrit : > > >> On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Perhaps I am too optimistic, and core team members correct me if I am >> speaking out of turn here, b

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

2017-08-09 12:50 GMT+09:00 Robert Bennett : It’s a shame that Range can’t be made to conform to SetAlgebra as it lacks the required initializers. Is there anything that can be done about this? Actually, it makes me wonder whether those initializers should even be a part of SetAlgebra — why must s

Re: [swift-evolution] SE-184 Improved Pointers

On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: > > On Aug 8, 2017, at 8:44 PM, Taylor Swift wrote: > > cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot > find such a function anywhere in the API. There is copyBytes(from:) >

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> If you’re into analogies, I see features like the generics improvements, > concurrency model, ownership system, macro system, ABI stability, new > frameworks, and other large scale efforts as the “bricks" that make up the > house of Swift. In that analogy, smaller proposals are “mortar” that

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

On Wed, Aug 9, 2017 at 1:50 AM, Rob Mayoff wrote: > On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users < > swift-us...@swift.org> wrote: > >> >> >> On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> Yes, exactly. An Array i

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 8:44 PM, Taylor Swift wrote: > > cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot find > such a function anywhere in the API. There is copyBytes(from:) >

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users < swift-us...@swift.org> wrote: > > > On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution < > swift-evolution@swift.org> wrote: > >> Yes, exactly. An Array is a struct wrapper for a reference type >> representing storage

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

2017-08-09 12:23 GMT+09:00 Xiaodi Wu : > For consistency, the name for this function would be `isSuperset(of:)`, and it would be equally interesting to have `isStrictSuperset(of:)`, `isSubset(of:)`, `isStrictSubset(of:)` and `isDisjoint(with:)`--all currently available for types that conform to `S

Re: [swift-evolution] Swift 5: start your engines

> On Aug 8, 2017, at 8:19 PM, Susan Cheng via swift-evolution > wrote: > > is it accept proposal for coroutine? > Just like the one i had proposed before: > https://github.com/apple/swift-evolution/pull/73 > Hi Susan, I’d love to see progres

Re: [swift-evolution] Enums and Source Compatibility

While I agree with the entire idea and would actually use behavior like this in a few instances, I feel that in most cases, you would simply put default: fatalError() The huge downside of this is that you no longer get warned by the compiler that you are missing a case that was added -

Re: [swift-evolution] How does "Sequence.joined" work?

On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution < swift-evolution@swift.org> wrote: > Yes, exactly. An Array is a struct wrapper for a reference type > representing storage. Mutating functions first check if they own the only > reference to the storage using isKnownUniquelyRefe

Re: [swift-evolution] How does "Sequence.joined" work?

Yes, exactly. An Array is a struct wrapper for a reference type representing storage. Mutating functions first check if they own the only reference to the storage using isKnownUniquelyReferenced . If not, they ma

[swift-evolution] ExpressibleByStringInterpolation

I had a proposal for replacing/reintroducing `ExpressibleByStringInterpolation` (which is currently deprecated pending a redesign), but it landed too late in the Swift 4 cycle to be considered. The PR is here: https://github.com/apple/swift-evolution/pull/659 I think it squares up relatively we

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

It’s a shame that Range can’t be made to conform to SetAlgebra as it lacks the required initializers. Is there anything that can be done about this? Actually, it makes me wonder whether those initializers should even be a part of SetAlgebra — why must something implementing SetAlgebra be able to

Re: [swift-evolution] SE-184 Improved Pointers

cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot find such a function anywhere in the API. There is copyBytes(from:) , but the documentation is messed up and mentions a nonexisten

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 8:29 PM, Taylor Swift wrote: > > > > On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick > wrote: > >> On Aug 8, 2017, at 6:51 PM, Taylor Swift > > wrote: >> >> >> >> On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick >

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick wrote: > > On Aug 8, 2017, at 6:51 PM, Taylor Swift wrote: > > > > On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick wrote: > >> >> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:) >>> >>> Well, I think it's somewhat ridiculous for users to wri

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 6:51 PM, Taylor Swift wrote: > > > > On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick > wrote: > >> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:) >> >> Well, I think it's somewhat ridiculous for users to write this every time >> they a

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

For consistency, the name for this function would be `isSuperset(of:)`, and it would be equally interesting to have `isStrictSuperset(of:)`, `isSubset(of:)`, `isStrictSubset(of:)` and `isDisjoint(with:)`--all currently available for types that conform to `SetAlgebra`. On Tue, Aug 8, 2017 at 9:40 P

Re: [swift-evolution] Swift 5: start your engines

is it accept proposal for coroutine? Just like the one i had proposed before: https://github.com/apple/swift-evolution/pull/73 2017-08-09 0:23 GMT+08:00 Ted Kremenek via swift-evolution < swift-evolution@swift.org>: > Hi everyone, > > The proposal phase for Swift 4 is now officially over, and the

[swift-evolution] [Pitch] range.contains(anotherRange)

Hi, Recently I needed to implement `contains` methods to check if a range contains another range. I think those are basic operations and suitable for the standard library. Although it may seem easy to implement such `contains` methods whenever we need them, their precise specifications are too co

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick wrote: > > > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:) >> >> Well, I think it's somewhat ridiculous for users to write this every time >> they allocate a buffer: >> >> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: >> Me

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 5:49 PM, Taylor Swift wrote: > > > > On Tue, Aug 8, 2017 at 7:53 PM, Andrew Trick > wrote: > >> On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Since Swift 5 just got opened up for

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

Real Swift code uses very very few “unicode” operators, so I would heavily tilt the division towards making most characters identifiers. While I don’t want to talk about specific characters, I often wish I could name variables `∇f` or `∂u∂v`, while no sane API designer would ever use `∇` or `∂` as

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 8, 2017 at 7:53 PM, Andrew Trick wrote: > > On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers > is ready for community review, and I encourage everyone to look

Re: [swift-evolution] Swift 5: start your engines

> On Aug 8, 2017, at 2:29 PM, Paul Cantrell wrote: > > I imagine that the core team will assist in providing implementations for > proposals that are crucial to the progress of the language and/or highly > popular — regardless of whether the proposal was authored by the core team or > a comm

Re: [swift-evolution] Swift 5: start your engines

> On Aug 8, 2017, at 3:06 PM, Erica Sadun wrote: > >> >> On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Perhaps I am too optimistic, and core team members correct me if I am >> speaking out of turn here, but… >> >> I imagine

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution > wrote: > > Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is > ready for community review, and I encourage everyone to look it over and > provide feedback. Thank you! >

Re: [swift-evolution] How does "Sequence.joined" work?

Daryle Walker via swift-evolution schrieb am Di. 8. Aug. 2017 um 21:25: > On Aug 8, 2017, at 12:35 AM, Félix Cloutier > wrote: > > All this means is that `joined()` does not create an array that contains > the new result. It's only as magic as the COW semantics on arrays. > > > So you’re saying

[swift-evolution] Enums and Source Compatibility

Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to an issue that's been around for a while: the source compatibility of enums. Today, it's an error to switch over an enum without handling all the cases, but this breaks down in a number of ways: - A C enum may have "privat

Re: [swift-evolution] Swift 5: start your engines

> On Aug 8, 2017, at 3:06 PM, Erica Sadun via swift-evolution > wrote: > >> I imagine that the core team will assist in providing implementations for >> proposals that are crucial to the progress of the language and/or highly >> popular — regardless of whether the proposal was authored by the

Re: [swift-evolution] SE-184 Improved Pointers

This is an excellent document that demonstrates great care and attention. It addresses pain points discovered through real-world use by a minimum of well-justified API changes. The motivating example is compelling, and my only suggestion there is to show a before-and-after comparison of how the pr

Re: [swift-evolution] Swift 5: start your engines

> On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution > wrote: > > Perhaps I am too optimistic, and core team members correct me if I am > speaking out of turn here, but… > > I imagine that the core team will assist in providing implementations for > proposals that are crucial to t

Re: [swift-evolution] Swift 5: start your engines

Perhaps I am too optimistic, and core team members correct me if I am speaking out of turn here, but… I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal w

Re: [swift-evolution] SE-184 Improved Pointers

> On 8 Aug 2017, at 17:53, Taylor Swift via swift-evolution > wrote: > > Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is > ready for community review, and I encourage everyone to look it over and > provide feedback. Thank you! >

Re: [swift-evolution] How does "Sequence.joined" work?

> On Aug 8, 2017, at 3:24 PM, Daryle Walker via swift-evolution > wrote: >> On Aug 8, 2017, at 12:35 AM, Félix Cloutier > > wrote: >> >> All this means is that `joined()` does not create an array that contains the >> new result. It's only as magic as the COW sem

Re: [swift-evolution] How does "Sequence.joined" work?

> On Aug 8, 2017, at 12:35 AM, Félix Cloutier wrote: > > All this means is that `joined()` does not create an array that contains the > new result. It's only as magic as the COW semantics on arrays. So you’re saying the COW semantics for Array and other standard library types have secret refer

[swift-evolution] [Pitch][Swift 5?] #dup "macro", i.e. Entity Duplication

I posted a revision (2) of the entity duplication . I added the ability to use the index placeholder as a closure anonymous argument, i.e. parameterize “$0,” “$1,” etc. with “$($$0).” I thought a direct triple-dollar-sign would

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

Perfect, thanks! On Tue, Aug 8, 2017 at 7:25 PM, Douglas Gregor wrote: > On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution < > swift-evolution@swift.org> wrote: > > Sorry to revive this, but back on my ABI stability education: > > > [We’re a bit far afield of the original subject,

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution > wrote: > > Sorry to revive this, but back on my ABI stability education: [We’re a bit far afield of the original subject, but okay] > > Swift 5 planning was announced today (woohoo!) with a primary target on ABI > stabilit

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

The key difference is whether such things can be rolled out in the future in an additive way, potentially with extra compatibility affordances, vs whether something is inherent to the ABI as Swift and the standard library currently exists. This is a very fuzzy line, and is constantly getting ree

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

I would like to add something to this discussion on casting generics. I think there is a temptation to think of generic types as having a protocol-like aspect. If String conforms to Any, then a [String] ought to conform to [Any]; the current scope may think of the variable as being a [Any] even th

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

Sorry to revive this, but back on my ABI stability education: Swift 5 planning was announced today (woohoo!) with a primary target on ABI stability. Finalising generics seems to be a major part of this, with "conditional conformances", "recursive protocol requirements," and "there are no known oth

Re: [swift-evolution] Swift 5: start your engines

Thank you for the kind updates Ted. However I already feel the negative impact because of the last restriction. I also would like to point out that, personally I think until the swift-evolution is not moved to a forum this will only create a great wall between proposal authors and people that ar

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> On Aug 7, 2017, at 11:34 PM, Elviro Rocca > wrote: > > I agree with everything you wrote, in particular I agree with the idea that > it is more important to get the big efforts right, and that they should take > priority. But I would consider a distinction: > > - big efforts that add huge

[swift-evolution] SE-184 Improved Pointers

Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is ready for community review, and I encourage everyone to look it over and provide feedback. Thank you! < https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md >

[swift-evolution] Swift 5: start your engines

Hi everyone, The proposal phase for Swift 4 is now officially over, and the release is now in endgame engineering convergence for an expected release later this year. Swift 4 has turned out to be one of the highest quality, well-rounded releases of Swift, and I am grateful to everyone in the c

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

> On Aug 8, 2017, at 06:38, Karl Wagner wrote: > > >>> On 8. Aug 2017, at 04:35, David Sweeris via swift-evolution >>> wrote: >>> >>> >>> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution >>> wrote: >>> >>> One of my longstanding frustrations with generic types and protocols ha

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

> On 8. Aug 2017, at 04:35, David Sweeris via swift-evolution > wrote: > >> >> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> One of my longstanding frustrations with generic types and protocols has >> been how hard it is to wo

Re: [swift-evolution] [Pitch?] Way to declare a Swift Array that guarantees it can't be empty

> Fixed-size arrays do not solve this particular issue that I've noted above. And I didn't say so ;-) But generic value parameters would not only allow you to define fixed-size arrays, but also arrays with certain other properties: Minimal size, maximal size… maybe even number of elements or othe

Re: [swift-evolution] [Pitch?] Way to declare a Swift Array that guarantees it can't be empty

I had a similar though some time ago (and even suggested it here) - as e.g. "Hello".components(separatedBy: "123") will always produce a non-empty array. Even "".components(separatedBy: "") is [""]. Which would allow e.g. first, last and some other members to loose the optionality - which would

[swift-evolution] [Pitch?] Way to declare a Swift Array that guarantees it can't be empty

You would have this guarantee with the fixed-size arrays currently being discussed. Perhaps this could be an amendment to that proposal - you could declare an array with bounds for its size. Fixed-size arrays would be a subset of those where the upper and lower bounds are equal. They could also

Re: [swift-evolution] [Pitch?] Way to declare a Swift Array that guarantees it can't be empty

I think it would make sense to have arrays with a minimal size, but wouldn't consider it very important. But there is a long-running discussion about fixed-size arrays, and depending on (if any) solution is chosen for them, your use case could be solved rather easy as well. _

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

I see what you're saying, and I agree that this is more of a half-measure. But the benefit of this approach is that it's pretty trivial to implement, and the language features it introduces could be reimplemented with existentialists when they become available. I think advancing the syntax of the l

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

To my understanding, the following is exactly as it should be: FooStruct as? FooStruct // Compiles but conversion fails, becomes nil, and that's normal The reason for this is that FooStruct is not a subtype of FooStruct (or just FooStruct), while String is of course a subtype of Any, because g

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

Thanks for the feedback! Félix, sorry about the confusion between FooStruct and FooProtocol - I'll refer to them as such moving forwards. David, I don't believe you should be able to cast an [FooStruct] to an [FooStruct] because those are both valid specifications. If Generalized Existentials

[swift-evolution] [Pitch?] Way to declare a Swift Array that guarantees it can't be empty

This isn't a fully formed pitch, and maybe already discussed, but... If we have have optionals and non-optionals, shouldn't we also have a way to declare that an Array never be empty? It seems like this would naturally lead to more elegant designs. Here's a use-case: struct Wavelet { var buff: [

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

Covariant generic types make for an unsound type system. I believe the reason why Array and Optional are covariant in their generic parameter is that the way their implementation interacts with their internal storage assures that new storage is created if types mismatch: this means that to make

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

I'm going to separate your examples into FooStruct and FooProtocol for clarity. I agree that generics tend to propagate virally and I remember that at some point I wanted type erasure, though I don't remember for what exactly. The solution for `sayHi`, right now, is to make that one generic too: