Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Sent from my iPhone > On 3 Jan 2018, at 07:42, Goffredo Marocchi wrote: > > >> On 3 Jan 2018, at 02:07, Jordan Rose via swift-evolution >> wrote: >> >> [Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md] >> >> Whew! Thanks for your f

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

This is not what I am saying. Change X helps use case A, but unnecessarily removes feature important (and like argument labels for everything quite Swift defining, but alas...) for use case B. What I am saying is that before merging change X we should figure out what is needed (change Y) to en

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

I am not convinced by these arguments, they seem to be a ‘poor man’s’ versioning system. For example consider: // In module. public enum E { case A, B, C } // In application. switch e { case A: a() default: d() unknown case: u() } When e == B or C i

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 11:45 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > On Tue, Jan 2, 2018 at 9:07 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > >> [Proposal: https://github.com/apple/swift-evolution/blob/mas >> ter/proposals/0192-non-exhaustive-enums.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 9:07 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > [Proposal: https://github.com/apple/swift-evolution/blob/ > master/proposals/0192-non-exhaustive-enums.md] > > Whew! Thanks for your feedback, everyone. On the lighter side of > feedback—naming th

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 8:49 PM, Matthew Johnson wrote: > > On Jan 2, 2018, at 8:45 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Jan 2, 2018 at 8:07 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > >> [Proposal: https://github.com/a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 2, 2018, at 8:45 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jan 2, 2018 at 8:07 PM, Jordan Rose via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 2, 2018, at 8:07 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > > ] > > Whew! Th

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 8:07 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > [Proposal: https://github.com/apple/swift-evolution/blob/ > master/proposals/0192-non-exhaustive-enums.md] > > Whew! Thanks for your feedback, everyone. On the lighter side of > feedback—naming th

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 8:25 PM, Matthew Johnson wrote: > > On Jan 2, 2018, at 3:41 PM, Xiaodi Wu wrote: > > On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger > wrote: > >> [...] >> >> in what other circumstances do we insist that the compiler inform the end >>> user about future additions to the

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 2, 2018, at 2:09 PM, Xiaodi Wu wrote: > > On Tue, Jan 2, 2018 at 1:46 PM, Matthew Johnson > wrote: > > > Sent from my iPad > > On Jan 2, 2018, at 12:48 PM, Xiaodi Wu > wrote: > >> On Tue, Jan 2, 2018 at 9:38 AM, Matthew Jo

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 2, 2018, at 3:41 PM, Xiaodi Wu wrote: > > On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger > wrote: > [...] > >>> in what other circumstances do we insist that the compiler inform the end >>> user about future additions to the API at compile time? >> >> Th

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md ] Whew! Thanks for your feedback, everyone. On the lighter side of feedback—naming things—it seems

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 7:02 PM, Goffredo Marocchi wrote: > > On 3 Jan 2018, at 00:38, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Jan 2, 2018 at 4:31 PM, Jonathan Hull wrote: > >> I think there are a couple of different definitions running around, and >> that

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On 3 Jan 2018, at 00:38, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Jan 2, 2018 at 4:31 PM, Jonathan Hull wrote: >> I think there are a couple of different definitions running around, and that >> is confusing things. >> >> In my mind, ‘unexpected:’ catches only cases which were un

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 4:31 PM, Jonathan Hull wrote: > I think there are a couple of different definitions running around, and > that is confusing things. > > In my mind, ‘unexpected:’ catches only cases which were unknown at compile > time. Adding cases to an enum *should* be a source-breaking c

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

In regards of A, doesn’t this code cover al cases? @incomplete enum { case pancake case waffle case juice } When the @incomplete tag is present, the compiler enforces (with an error) that all switches handle a default case: switch breakfast { case .pancake: case .waffle: case .juice

Re: [swift-evolution] [swift-dev] Make offset index available for String

And really, this is more an issue for swift-evolution, since what you’re talking about (self-incrementing indexes) would be a new language feature. - Karl > On 3. Jan 2018, at 01:19, Karl Wagner wrote: > > Swift used to do this, but we switched it around so indexes couldn’t > self-increment.

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

I think there are a couple of different definitions running around, and that is confusing things. In my mind, ‘unexpected:’ catches only cases which were unknown at compile time. Adding cases to an enum *should* be a source-breaking change. That is the whole point of this. We should have to up

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

I think this is a good summary. I agree that we need to handle unexpected cases from changes to a binary somehow. The main issue is that, when forcing developers to use ‘default’ to do it, it also brings along unwanted semantics that prevent warnings in the very common use case of a 3rd part

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger wrote: > [...] > > in what other circumstances do we insist that the compiler inform the end >> user about future additions to the API at compile time? >> >> >> This isn’t a request for the compiler to inform the user about future >> additions to an

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[...] >> in what other circumstances do we insist that the compiler inform the end >> user about future additions to the API at compile time? > > This isn’t a request for the compiler to inform the user about future > additions to an API. It is a request to validate the compiler’s knowledge of

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On 2. Jan 2018, at 16:38, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Jan 1, 2018, at 11:47 PM, Chris Lattner > wrote: > >>> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution >>> mailto:swift-evolution@swift.

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 1:46 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Jan 2, 2018, at 12:48 PM, Xiaodi Wu wrote: > > On Tue, Jan 2, 2018 at 9:38 AM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> Sent from my iPad >> >> On Jan 1, 2018, at 11:

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Sent from my iPad > On Jan 2, 2018, at 12:48 PM, Xiaodi Wu wrote: > >> On Tue, Jan 2, 2018 at 9:38 AM, Matthew Johnson via swift-evolution >> wrote: >> >> >> Sent from my iPad >> >> On Jan 1, 2018, at 11:47 PM, Chris Lattner wrote: >> On Dec 31, 2017, at 12:14 PM, Matthew Johnson v

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 1:27 PM, Goffredo Marocchi wrote: > Hello all, > > On 2 Jan 2018, at 18:36, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution < > swift-evolution@swift.org> wrote: > >> I think this wh

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Hello all, > On 2 Jan 2018, at 18:36, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution >> wrote: >> I think this whole thing has been unnecessarily convoluted. As a result, the >> majority of the replies are rabbit holes. >> >>

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

On Fri, Dec 22, 2017 at 11:12 PM, Slava Pestov wrote: > > > On Dec 22, 2017, at 7:09 PM, Xiaodi Wu wrote: > > On Fri, Dec 22, 2017 at 6:12 PM, Chris Lattner > wrote: > >> >> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu wrote: >> >> In short, respectfully request that you at least add this approach t

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 9:38 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On Jan 1, 2018, at 11:47 PM, Chris Lattner wrote: > > On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > > I a

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution < swift-evolution@swift.org> wrote: > I think this whole thing has been unnecessarily convoluted. As a result, > the majority of the replies are rabbit holes. > > In my opinion, the true root of the concept in question is as follo

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

On Tue, Jan 2, 2018 at 10:19 AM, Dave DeLong via swift-evolution < swift-evolution@swift.org> wrote: > Just skimmed through the updated proposal and am weighing in with my naïve > opinions: > > >- I’m still highly skeptical of a static “T.random” API. I’ve yet to >see a convincing example

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

I'm not sure how much background you have into this thread, but the idea of sources and distributions was rejected months ago as almost always too cumbersome given that people overwhelmingly want uniform random numbers. I agree that random() is better as a method. I also think that the default

Re: [swift-evolution] [swift-users] Happy new year Swift community.

Happy New Year from Canada 🇨🇦! On Jan 1, 2018, at 14:02, Kelvin Ma via swift-users mailto:swift-us...@swift.org>> wrote: Happy new year from klossyland! On Mon, Jan 1, 2018 at 11:23 AM, Georgios Moschovitis via swift-users mailto:swift-us...@swift.org>> wrote: Happy new year! Greetings from Cy

Re: [swift-evolution] [arc optimization] Why doesn't enum destructuring use guaranteed references?

This is a great question, I’m not sure what the answer is: maybe it is a simple case missed by the arc optimizer? -Chris > On Dec 27, 2017, at 9:19 PM, Félix Cloutier via swift-evolution > wrote: > > Running this on my MBP with 10 as the parameter: > https://gist.github.com/zneak/ae33bb9

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

I think this whole thing has been unnecessarily convoluted. As a result, the majority of the replies are rabbit holes. In my opinion, the true root of the concept in question is as follows: *A list of something is desired:* 1 - Pancake 2 - Waffle 3 - Juice *Developer wishes to be able to:* *A)*

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

> On Dec 21, 2017, at 10:59 AM, Dave Abrahams wrote: > > > >> On Dec 21, 2017, at 10:19 AM, Ethan Diamond > > wrote: >> >> Just to clarify, Dave - >> >> What happens there if one case has associated values > >> and one has an associated value thats an optiona

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

Just skimmed through the updated proposal and am weighing in with my naïve opinions: I’m still highly skeptical of a static “T.random” API. I’ve yet to see a convincing example where it’d be useful to pick a value from the range of all possible values. The only truly useful one I’ve seen is “pi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

First, this is an extremely well-written proposal, that explains itself well and tries to walk a difficult tightrope.  So, A+ for that. That said, I think it needs modification before acceptance: * I agree with Dave DeLong that @exhaustive does not actually "do anything", it relies on library a

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Sent from my iPad >> On Jan 1, 2018, at 11:47 PM, Chris Lattner wrote: >> >> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution >> wrote: >> >> I agree that we need a solution to the problem described. I also agree that >> non-exhaustive is most in keeping with the overall

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

We use enums also when modeling JSON responses from our servers. To allow the server side to add new cases without breaking existing clients, we always add an `undefined` case to our enums. Binary frameworks might do the same when exporting enums. When clients compile to a newer version of the fra

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

On Tue, Jan 2, 2018 at 2:35 AM, Alejandro Alonso via swift-evolution < swift-evolution@swift.org> wrote: > Hello swift evolution once again, I’ve been hard at work considering every > email and revising the proposal. I’ve made lots of changes and additions to > the proposal to discuss some problem

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Tue, Jan 2, 2018 at 12:47 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > 1) When dealing with independently updated binary packages, your code > *has* to implement some behavior for unexpected cases if the enum is > non-exhaustive. It isn’t acceptable to not han

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

Hello swift evolution once again, I’ve been hard at work considering every email and revising the proposal. I’ve made lots of changes and additions to the proposal to discuss some problems we’ve had (T.random), and walks through detailed design. You can see the proposal here: https://github.com