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

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

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

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

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

[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

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:

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:) >>>

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

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

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

[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

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:

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 >>

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 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

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

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

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 >

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

[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

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

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

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

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

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

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

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:

[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

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: >>>

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

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

[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

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

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

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

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 new features to the language so that things that were done in