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

[Xiaodi Wu via swift-evolution]

As has already been said, “case unknown” is source-breaking because it
conflicts with any real cases named “unknown”; “\unknown” looks like a key
path but isn’t, and I wonder if it would potentially conflict with existing
key paths.

In any case, my point was not to bikeshed the “unknown” part, but to ask
whether any consideration had been made to have the feature presented as a
flavor of default instead of a flavor of case.

On Wed, Jan 3, 2018 at 23:57 Cheyo Jimenez  wrote:

>
>
> On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is a very nice revision. One bikeshedding thought:
>
> Since "unknown case" is presented as a special kind of "default", can't be
> mixed with "default", and can't be used in case patterns, why not "default
> unknown" (or "unknown default") instead of "unknown case"?
>
>
> `case _ :` is already a special case of default.
> I’d rather have `case unknown :`
> `unknown case :` is weird because of the order of `case`.
>
> Another alternative is `case \unknown :`
> `\unknown` would also allow pattern matching.
>
>
>
>
>
> On Wed, Jan 3, 2018 at 8:05 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jan 2, 2018, at 18:07, Jordan Rose  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 things—it seems that most people seem to like '*@frozen*',
>> and that does in fact have the connotations we want it to have. I like it
>> too.
>>
>> More seriously, this discussion has convinced me that it's worth
>> including what the proposal discusses as a *'future' case*. The key
>> point that swayed me is that this can produce a *warning* when the
>> switch is missing a case rather than an *error,* which both provides the
>> necessary compiler feedback to update your code and allows your
>> dependencies to continue compiling when you update to a newer SDK. I know
>> people on both sides won't be 100% satisfied with this, but does it seem
>> like a reasonable compromise?
>>
>> The next question is how to spell it. I'm leaning towards `unexpected
>> case:`, which (a) is backwards-compatible, and (b) also handles "private
>> cases", either the fake kind that you can do in C (as described in the
>> proposal), or some real feature we might add to Swift some day. `unknown
>> case:` isn't bad either.
>>
>> I too would like to just do `unknown:` or `unexpected:` but that's
>> technically a source-breaking change:
>>
>> switch foo {
>> case bar:
>>   unknown:
>>   while baz() {
>> while garply() {
>>   if quux() {
>> break unknown
>>   }
>> }
>>   }
>> }
>>
>>
>> Another downside of the `unexpected case:` spelling is that it doesn't
>> work as part of a larger pattern. I don't have a good answer for that one,
>> but perhaps it's acceptable for now.
>>
>> I'll write up a revision of the proposal soon and make sure the core team
>> gets my recommendation when they discuss the results of the review.
>>
>> ---
>>
>> I'll respond to a few of the more intricate discussions tomorrow,
>> including the syntax of putting a new declaration inside the enum rather
>> than outside. Thank you again, everyone, and happy new year!
>>
>>
>> I ended up doing these in the opposite order, writing up the new proposal
>> first and not yet responding to the discussion that's further out. You can
>> read my revisions at https://github.com/apple/swift-evolution/pull/777.
>>
>> In particular, I want to at least address:
>> - Dave D and Drew C's points about versioned libraries / linking
>> semantics of modules.
>> - Jason M's point about migration
>> and I'll do one more pass over the thread to see if there's anything else
>> I didn't address directly. (That doesn't mean everyone who disagrees, just
>> messages where I think there's more I can do to explain why the proposal is
>> the way it is.)
>>
>> Jordan
>>
>> P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-)
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Cheyo Jimenez via swift-evolution]

> On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> This is a very nice revision. One bikeshedding thought:
> 
> Since "unknown case" is presented as a special kind of "default", can't be 
> mixed with "default", and can't be used in case patterns, why not "default 
> unknown" (or "unknown default") instead of "unknown case"?

`case _ :` is already a special case of default. 
I’d rather have `case unknown :`
`unknown case :` is weird because of the order of `case`. 

Another alternative is `case \unknown :`
`\unknown` would also allow pattern matching. 



> 
> 
> On Wed, Jan 3, 2018 at 8:05 PM, Jordan Rose via swift-evolution 
>  wrote:
>>> On Jan 2, 2018, at 18:07, Jordan Rose  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 things—it seems that most people seem to like '@frozen', 
>>> and that does in fact have the connotations we want it to have. I like it 
>>> too.
>>> 
>>> More seriously, this discussion has convinced me that it's worth including 
>>> what the proposal discusses as a 'future' case. The key point that swayed 
>>> me is that this can produce a warning when the switch is missing a case 
>>> rather than an error, which both provides the necessary compiler feedback 
>>> to update your code and allows your dependencies to continue compiling when 
>>> you update to a newer SDK. I know people on both sides won't be 100% 
>>> satisfied with this, but does it seem like a reasonable compromise?
>>> 
>>> The next question is how to spell it. I'm leaning towards `unexpected 
>>> case:`, which (a) is backwards-compatible, and (b) also handles "private 
>>> cases", either the fake kind that you can do in C (as described in the 
>>> proposal), or some real feature we might add to Swift some day. `unknown 
>>> case:` isn't bad either.
>>> 
>>> I too would like to just do `unknown:` or `unexpected:` but that's 
>>> technically a source-breaking change:
>>> 
>>> switch foo {
>>> case bar:
>>>   unknown:
>>>   while baz() {
>>> while garply() {
>>>   if quux() {
>>> break unknown
>>>   }
>>> }
>>>   }
>>> }
>>> 
>>> Another downside of the `unexpected case:` spelling is that it doesn't work 
>>> as part of a larger pattern. I don't have a good answer for that one, but 
>>> perhaps it's acceptable for now.
>>> 
>>> I'll write up a revision of the proposal soon and make sure the core team 
>>> gets my recommendation when they discuss the results of the review.
>>> 
>>> ---
>>> 
>>> I'll respond to a few of the more intricate discussions tomorrow, including 
>>> the syntax of putting a new declaration inside the enum rather than 
>>> outside. Thank you again, everyone, and happy new year!
>> 
>> I ended up doing these in the opposite order, writing up the new proposal 
>> first and not yet responding to the discussion that's further out. You can 
>> read my revisions at https://github.com/apple/swift-evolution/pull/777.
>> 
>> In particular, I want to at least address:
>> - Dave D and Drew C's points about versioned libraries / linking semantics 
>> of modules.
>> - Jason M's point about migration
>> and I'll do one more pass over the thread to see if there's anything else I 
>> didn't address directly. (That doesn't mean everyone who disagrees, just 
>> messages where I think there's more I can do to explain why the proposal is 
>> the way it is.)
>> 
>> Jordan
>> 
>> P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-)
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

This is a very nice revision. One bikeshedding thought:

Since "unknown case" is presented as a special kind of "default", can't be
mixed with "default", and can't be used in case patterns, why not "default
unknown" (or "unknown default") instead of "unknown case"?


On Wed, Jan 3, 2018 at 8:05 PM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jan 2, 2018, at 18:07, Jordan Rose  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 things—it seems that most people seem to like '*@frozen*',
> and that does in fact have the connotations we want it to have. I like it
> too.
>
> More seriously, this discussion has convinced me that it's worth including
> what the proposal discusses as a *'future' case*. The key point that
> swayed me is that this can produce a *warning* when the switch is missing
> a case rather than an *error,* which both provides the necessary compiler
> feedback to update your code and allows your dependencies to continue
> compiling when you update to a newer SDK. I know people on both sides won't
> be 100% satisfied with this, but does it seem like a reasonable compromise?
>
> The next question is how to spell it. I'm leaning towards `unexpected
> case:`, which (a) is backwards-compatible, and (b) also handles "private
> cases", either the fake kind that you can do in C (as described in the
> proposal), or some real feature we might add to Swift some day. `unknown
> case:` isn't bad either.
>
> I too would like to just do `unknown:` or `unexpected:` but that's
> technically a source-breaking change:
>
> switch foo {
> case bar:
>   unknown:
>   while baz() {
> while garply() {
>   if quux() {
> break unknown
>   }
> }
>   }
> }
>
>
> Another downside of the `unexpected case:` spelling is that it doesn't
> work as part of a larger pattern. I don't have a good answer for that one,
> but perhaps it's acceptable for now.
>
> I'll write up a revision of the proposal soon and make sure the core team
> gets my recommendation when they discuss the results of the review.
>
> ---
>
> I'll respond to a few of the more intricate discussions tomorrow,
> including the syntax of putting a new declaration inside the enum rather
> than outside. Thank you again, everyone, and happy new year!
>
>
> I ended up doing these in the opposite order, writing up the new proposal
> first and not yet responding to the discussion that's further out. You can
> read my revisions at https://github.com/apple/swift-evolution/pull/777.
>
> In particular, I want to at least address:
> - Dave D and Drew C's points about versioned libraries / linking semantics
> of modules.
> - Jason M's point about migration
> and I'll do one more pass over the thread to see if there's anything else
> I didn't address directly. (That doesn't mean everyone who disagrees, just
> messages where I think there's more I can do to explain why the proposal is
> the way it is.)
>
> Jordan
>
> P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-)
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Preserving non-mutability of methods of an existential or generic object

[Slava Pestov via swift-evolution]

> On Jan 3, 2018, at 5:33 PM, Hooman Mehr  wrote:
> 
> Thank you Slava, it is a very insightful answer. 
> 
> It also reveals a potential source for hard to track bugs. To make it easier 
> to see, lets add state to class C:
> 
> class D: C { var state = 0 }
> 
> var d = D() // Bad but common habit of declaring objects as var
> for i in 1...5 { d.f(i); d.state += 1 }
> print(d.state) // Prints 1
> 
> The result is surprising because a typical programmer does not expect an 
> object to have mutating methods (that replace the object itself with a 
> different one).
> 
> I think this is a bug in Swift compiler. It should not let a class “inherit” 
> a mutating method in this manner. Compiler should require a non-mutating 
> declaration of `f()` to satisfy `P` conformance for a class type.

Perhaps, but it’s also possible to define a mutating method g() in a protocol 
extension of P, where g() is not a protocol requirement. Calling g() on a class 
instance can “replace” self in this manner also.

> If we fix the above, it should be possible to do what I asked in my post: 
> When compiler knows an existential is an object, it should know all methods 
> are non-mutating and accept `let` declaration despite calls to nominally 
> mutating methods. Also, if a protocol refines another protocol to be 
> class-bound, compiler should automatically refine all of its inherited 
> mutating methods to be non-mutating and allow `let` declaration of an 
> existential of that protocol even if there are calls to those originally 
> mutating methods. 

This will prevent you from defining default implementations of protocol 
requirements in protocol extensions, which would be a source-breaking change at 
this point. I don’t think we can make such a change now.

Slava

> 
> Hooman
> 
>> On Dec 21, 2017, at 10:59 PM, Slava Pestov > > wrote:
>> 
>> Hi Hooman,
>> 
>> Since the protocol P is not class-bounded, the requirement can be witnessed 
>> by a protocol extension method which re-assigns ‘self’:
>> 
>> protocol Initable {
>>   init()
>> }
>> 
>> extension P where Self : Initable {
>>   mutating func f(_ x: Int) -> Int {
>> self = Self()
>> return x
>>   }
>> }
>> 
>> class C : P, Initable {
>>   required init() {}
>> }
>> 
>> Now imagine you could do this,
>> 
>> let x: P & AnyObject
>> 
>> x.f(12)
>> 
>> This would be invalid because ‘x’ is a let binding but the requirement ‘f’ 
>> is witnessed by the protocol extension method, which performs a mutating 
>> access of ‘self’.
>> 
>> Slava
>> 
>>> On Dec 21, 2017, at 6:01 PM, Hooman Mehr via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> The title is confusing, let me clarify by example:
>>> 
>>> We have this protocol with a mutating method:
>>> 
>>> protocol P { mutating func f(_ x: Int) -> Int }
>>> 
>>> And a conforming class (which has to conform with a non-mutating method):
>>> 
>>> class C: P { func f(_ x: Int) -> Int { return x } }
>>> 
>>> An instance of this class can be used with a let constant:
>>> 
>>> let c = C()
>>> c.f(1) // OK
>>>  
>>> If we make it an existential object conforming to P, the immutability of 
>>> the method will be erased:
>>> 
>>> let c: AnyObject & P = C()
>>> c.f(1) // Cannot use mutating member on immutable value: 'c' is a 'let' 
>>> constant
>>> 
>>> A generic context has the same issue:
>>> 
>>> func f(_ arg: T)-> Int { return arg.f(1) } // Cannot use 
>>> mutating member on immutable value: ‘arg' is a 'let' constant
>>> 
>>> My question: 
>>> 
>>> Is it too much work to preserve method non-mutability in in these cases?
>>> 
>>> The workaround I am using is this:
>>> 
>>> protocol Q: class, P { func f(_ x: Int) -> Int } // 'Refine' it to be 
>>> non-mutating.
>>> extension C: Q {}
>>> 
>>> // Now these work:
>>> let c: Q = C()
>>> c.f(1) // OK
>>> func f(_ arg: T)-> Int { return arg.f(1) } // OK
>>> 
>>> This workaround creates a lot of duplication and is hard to maintain. It is 
>>> not something that I do often, but when I do, it is pretty annoying. 
>>> 
>>> Supplemental questions:
>>> 
>>> Have you guys ever ran into this?
>>> Is there already a bug tracking this? 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Jan 2, 2018, at 18:07, Jordan Rose  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 things—it seems that most people seem to like '@frozen', and 
> that does in fact have the connotations we want it to have. I like it too.
> 
> More seriously, this discussion has convinced me that it's worth including 
> what the proposal discusses as a 'future' case. The key point that swayed me 
> is that this can produce a warning when the switch is missing a case rather 
> than an error, which both provides the necessary compiler feedback to update 
> your code and allows your dependencies to continue compiling when you update 
> to a newer SDK. I know people on both sides won't be 100% satisfied with 
> this, but does it seem like a reasonable compromise?
> 
> The next question is how to spell it. I'm leaning towards `unexpected case:`, 
> which (a) is backwards-compatible, and (b) also handles "private cases", 
> either the fake kind that you can do in C (as described in the proposal), or 
> some real feature we might add to Swift some day. `unknown case:` isn't bad 
> either.
> 
> I too would like to just do `unknown:` or `unexpected:` but that's 
> technically a source-breaking change:
> 
> switch foo {
> case bar:
>   unknown:
>   while baz() {
> while garply() {
>   if quux() {
> break unknown
>   }
> }
>   }
> }
> 
> Another downside of the `unexpected case:` spelling is that it doesn't work 
> as part of a larger pattern. I don't have a good answer for that one, but 
> perhaps it's acceptable for now.
> 
> I'll write up a revision of the proposal soon and make sure the core team 
> gets my recommendation when they discuss the results of the review.
> 
> ---
> 
> I'll respond to a few of the more intricate discussions tomorrow, including 
> the syntax of putting a new declaration inside the enum rather than outside. 
> Thank you again, everyone, and happy new year!

I ended up doing these in the opposite order, writing up the new proposal first 
and not yet responding to the discussion that's further out. You can read my 
revisions at https://github.com/apple/swift-evolution/pull/777.

In particular, I want to at least address:
- Dave D and Drew C's points about versioned libraries / linking semantics of 
modules.
- Jason M's point about migration
and I'll do one more pass over the thread to see if there's anything else I 
didn't address directly. (That doesn't mean everyone who disagrees, just 
messages where I think there's more I can do to explain why the proposal is the 
way it is.)

Jordan

P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Preserving non-mutability of methods of an existential or generic object

[Hooman Mehr via swift-evolution]

Thank you Slava, it is a very insightful answer. 

It also reveals a potential source for hard to track bugs. To make it easier to 
see, lets add state to class C:

class D: C { var state = 0 }

var d = D() // Bad but common habit of declaring objects as var
for i in 1...5 { d.f(i); d.state += 1 }
print(d.state) // Prints 1

The result is surprising because a typical programmer does not expect an object 
to have mutating methods (that replace the object itself with a different one).

I think this is a bug in Swift compiler. It should not let a class “inherit” a 
mutating method in this manner. Compiler should require a non-mutating 
declaration of `f()` to satisfy `P` conformance for a class type.

If we fix the above, it should be possible to do what I asked in my post: When 
compiler knows an existential is an object, it should know all methods are 
non-mutating and accept `let` declaration despite calls to nominally mutating 
methods. Also, if a protocol refines another protocol to be class-bound, 
compiler should automatically refine all of its inherited mutating methods to 
be non-mutating and allow `let` declaration of an existential of that protocol 
even if there are calls to those originally mutating methods. 

Hooman

> On Dec 21, 2017, at 10:59 PM, Slava Pestov  wrote:
> 
> Hi Hooman,
> 
> Since the protocol P is not class-bounded, the requirement can be witnessed 
> by a protocol extension method which re-assigns ‘self’:
> 
> protocol Initable {
>   init()
> }
> 
> extension P where Self : Initable {
>   mutating func f(_ x: Int) -> Int {
> self = Self()
> return x
>   }
> }
> 
> class C : P, Initable {
>   required init() {}
> }
> 
> Now imagine you could do this,
> 
> let x: P & AnyObject
> 
> x.f(12)
> 
> This would be invalid because ‘x’ is a let binding but the requirement ‘f’ is 
> witnessed by the protocol extension method, which performs a mutating access 
> of ‘self’.
> 
> Slava
> 
>> On Dec 21, 2017, at 6:01 PM, Hooman Mehr via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> The title is confusing, let me clarify by example:
>> 
>> We have this protocol with a mutating method:
>> 
>> protocol P { mutating func f(_ x: Int) -> Int }
>> 
>> And a conforming class (which has to conform with a non-mutating method):
>> 
>> class C: P { func f(_ x: Int) -> Int { return x } }
>> 
>> An instance of this class can be used with a let constant:
>> 
>> let c = C()
>> c.f(1) // OK
>>  
>> If we make it an existential object conforming to P, the immutability of the 
>> method will be erased:
>> 
>> let c: AnyObject & P = C()
>> c.f(1) // Cannot use mutating member on immutable value: 'c' is a 'let' 
>> constant
>> 
>> A generic context has the same issue:
>> 
>> func f(_ arg: T)-> Int { return arg.f(1) } // Cannot use 
>> mutating member on immutable value: ‘arg' is a 'let' constant
>> 
>> My question: 
>> 
>> Is it too much work to preserve method non-mutability in in these cases?
>> 
>> The workaround I am using is this:
>> 
>> protocol Q: class, P { func f(_ x: Int) -> Int } // 'Refine' it to be 
>> non-mutating.
>> extension C: Q {}
>> 
>> // Now these work:
>> let c: Q = C()
>> c.f(1) // OK
>> func f(_ arg: T)-> Int { return arg.f(1) } // OK
>> 
>> This workaround creates a lot of duplication and is hard to maintain. It is 
>> not something that I do often, but when I do, it is pretty annoying. 
>> 
>> Supplemental questions:
>> 
>> Have you guys ever ran into this?
>> Is there already a bug tracking this? 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl Wagner via swift-evolution]

> On 3. Jan 2018, at 18:49, Dave DeLong via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 3, 2018, at 10:36 AM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> IMO this is still too large of a hammer for this problem.
>>> 
>>> This whole “unexpected case” thing is only a problem when you’re linking 
>>> libraries that are external to/shipped independently of your app. Right 
>>> now, the *only* case where this might exist is Swift on the server. We 
>>> *might* run in to this in the future once the ABI stabilizes and we have 
>>> the Swift libraries shipping as part of iOS/macOS/Linux. Other than this, 
>>> unexpected enum cases won’t really be a problem developers have to deal 
>>> with.
>>> 
>>> Because this will be such a relatively rare problem, I feel like a syntax 
>>> change like what’s being proposed is a too-massive hammer for such a small 
>>> nail.
>>> 
>>> What feels far more appropriate is:
>>> 
>>> 🅰️ Teaching the compiler/checker/whatever about the linking semantics of 
>>> modules. For modules that are packaged inside the final built product, 
>>> there is no need to deal with any unexpected cases, because we already have 
>>> the exhaustiveness check appropriate for that scenario (regardless of 
>>> whether the module is shipped as a binary or compiled from source). The app 
>>> author decides when to update their dependencies, and updating those 
>>> dependencies will produce new warnings/errors as the compiler notices new 
>>> or deprecated cases. This is the current state of things and is completely 
>>> orthogonal to the entire discussion.
>> 
>> John McCall sketched out a vision of what a solution to this might look like 
>> here: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html
>>  
>> .
>>  
>> 
>>> 
>>> and
>>> 
>>> 🅱️ Adding an attribute (@frozen, @tangled, @moana, @whatever) that can be 
>>> used to decorate an enum declaration. This attribute would only need to be 
>>> consulted on enums where the compiler can determine that the module will 
>>> *not* be part of the final built product. (Ie, it’s an “external” module, 
>>> in my nomenclature). This, then, is a module that can update independently 
>>> of the final app, and therefore there are two possible cases:
>>> 
>>> 1️⃣ If the enum is decorated with @frozen, then I, as an app author, 
>>> have the assurance that the enum case will not change in future releases of 
>>> the library, and I can safely switch on all known cases and not have to 
>>> provide a default case. 
>>> 
>>> 2️⃣ If the enum is NOT decorated with @frozen, then I, as an app 
>>> author, have to account for the possibility that the module may update from 
>>> underneath my app, and I have to handle an unknown case. This is simple: 
>>> the compiler should require me to add a “default:” case to my switch 
>>> statement. This warning is produced IFF: the enum is coming from an 
>>> external module, and the enum is not decorated with @frozen.
>> 
>> This does not help people who need to write a switch statement over an enum 
>> vended by a module that ships with the OS keep their code up to date as the 
>> module adds new cases. I find the example of `SKPaymentTransactionState` 
>> provided by Brent Royal-Gordon here: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
>>  
>> 
>>  to be compelling.  There are rare but legitimate reasons to switch over all 
>> known cases of a non-@frozen enum that ship with the OS.  These use cases 
>> deserve proper language support.  I think Jordan’s solution strikes a good 
>> balance.
> 
> I disagree that more is needed. In the case of the transaction state, it 
> should not be marked as @moana, and so the compiler would force you to add a 
> “default” case to your switch statements. The switch statements would still 
> be exhaustive with all known cases (if you choose to handle all known cases), 
> but you’d still need a default case because there might be new transaction 
> states in the future.
> 
> In those cases, your app could decide what to do, if that’s possible at all. 
> Maybe there’s other transaction information you could introspect to determine 
> if it succeeded or is still pending or whatever, and then your app could 
> respond as you see fit.
> 
> Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
So here’s something that I’m confused about - you said before that when the 
library updates, the application beha

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jan 3, 2018, at 12:20 PM, Dave DeLong  wrote:
> 
> 
> 
>>> On Jan 3, 2018, at 11:09 AM, Matthew Johnson  wrote:
>>> 
>>> 
 On Jan 3, 2018, at 12:02 PM, Dave DeLong  wrote:
 
 
 
 On Jan 3, 2018, at 10:58 AM, Kevin Nattinger  wrote:
 
>>> [...]
>>> 2️⃣ If the enum is NOT decorated with @frozen, then I, as an 
>>> app author, have to account for the possibility that the module may 
>>> update from underneath my app, and I have to handle an unknown case. 
>>> This is simple: the compiler should require me to add a “default:” case 
>>> to my switch statement. This warning is produced IFF: the enum is 
>>> coming from an external module, and the enum is not decorated with 
>>> @frozen.
>> 
>> This does not help people who need to write a switch statement over an 
>> enum vended by a module that ships with the OS keep their code up to 
>> date as the module adds new cases. I find the example of 
>> `SKPaymentTransactionState` provided by Brent Royal-Gordon here: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
>>  to be compelling.  There are rare but legitimate reasons to switch over 
>> all known cases of a non-@frozen enum that ship with the OS.  These use 
>> cases deserve proper language support.  I think Jordan’s solution 
>> strikes a good balance.
> 
> I disagree that more is needed. In the case of the transaction state, it 
> should not be marked as @moana, and so the compiler would force you to 
> add a “default” case to your switch statements. The switch statements 
> would still be exhaustive with all known cases (if you choose to handle 
> all known cases), but you’d still need a default case because there might 
> be new transaction states in the future.
 
 And then you don't get the compiler error/warning when you start compiling 
 against the next OS update that changes the enum. That is an absolutely 
 unacceptable loss of compile-time checks.
>>> 
>>> Ah, that’s an excellent point! Thanks for pointing that out.
>>> 
>>> In that case, I revise my proposal:
>>> 
>>> 1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on 
>>> externally-linked modules
>>> 2️⃣ a “future case:” statement that’s only required on externally-linked, 
>>> non-@moana enums. That way, if the enum adds a new case in the future, 
>>> you’ll still get a switch warning about handling all the cases. And then if 
>>> you want, you could “fallthrough” from this to a “default” case, or 
>>> vice-versa, or have separate implementations.
>> 
>> It sounds to me like the main thing you’re unhappy about is having to deal 
>> with unknown cases when you have a source dependency that you always build 
>> and ship with an app.  I don’t think anyone is happy with that situation.  
> 
> That’s definitely part of it. The other main part is that I’m hugely 
> resistant to adding extraneous syntax when a solution that’s simpler for 
> users exists.

That’s fair.  If we didn’t have a compelling motivating example I would be more 
reluctant about the need to add syntax here, but we do have such an example.

> 
>> Did you take a look at the sketch of a solution provided by John McCall?  
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html
> 
> I’ve read that email several times and don’t understand how it relates.

I should have also linked to his previous email.  Does this one help clarify 
what he has in mind?  
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042329.html

> 
> Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave DeLong via swift-evolution]

> On Jan 3, 2018, at 11:09 AM, Matthew Johnson  wrote:
> 
>> 
>> On Jan 3, 2018, at 12:02 PM, Dave DeLong > > wrote:
>> 
>> 
>> 
>>> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger >> > wrote:
>>> 
>> [...]
>>  2️⃣ If the enum is NOT decorated with @frozen, then I, as an app 
>> author, have to account for the possibility that the module may update 
>> from underneath my app, and I have to handle an unknown case. This is 
>> simple: the compiler should require me to add a “default:” case to my 
>> switch statement. This warning is produced IFF: the enum is coming from 
>> an external module, and the enum is not decorated with @frozen.
> 
> This does not help people who need to write a switch statement over an 
> enum vended by a module that ships with the OS keep their code up to date 
> as the module adds new cases. I find the example of 
> `SKPaymentTransactionState` provided by Brent Royal-Gordon here: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
>  
> 
>  to be compelling.  There are rare but legitimate reasons to switch over 
> all known cases of a non-@frozen enum that ship with the OS.  These use 
> cases deserve proper language support.  I think Jordan’s solution strikes 
> a good balance.
 
 I disagree that more is needed. In the case of the transaction state, it 
 should not be marked as @moana, and so the compiler would force you to add 
 a “default” case to your switch statements. The switch statements would 
 still be exhaustive with all known cases (if you choose to handle all 
 known cases), but you’d still need a default case because there might be 
 new transaction states in the future.
>>> 
>>> And then you don't get the compiler error/warning when you start compiling 
>>> against the next OS update that changes the enum. That is an absolutely 
>>> unacceptable loss of compile-time checks.
>> 
>> Ah, that’s an excellent point! Thanks for pointing that out.
>> 
>> In that case, I revise my proposal:
>> 
>> 1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on 
>> externally-linked modules
>> 2️⃣ a “future case:” statement that’s only required on externally-linked, 
>> non-@moana enums. That way, if the enum adds a new case in the future, 
>> you’ll still get a switch warning about handling all the cases. And then if 
>> you want, you could “fallthrough” from this to a “default” case, or 
>> vice-versa, or have separate implementations.
> 
> It sounds to me like the main thing you’re unhappy about is having to deal 
> with unknown cases when you have a source dependency that you always build 
> and ship with an app.  I don’t think anyone is happy with that situation.  

That’s definitely part of it. The other main part is that I’m hugely resistant 
to adding extraneous syntax when a solution that’s simpler for users exists.

> Did you take a look at the sketch of a solution provided by John McCall?  
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html
>  
> 
I’ve read that email several times and don’t understand how it relates.

Dave___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 3, 2018, at 12:02 PM, Dave DeLong  wrote:
> 
> 
> 
>> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger > > wrote:
>> 
> [...]
>   2️⃣ If the enum is NOT decorated with @frozen, then I, as an app 
> author, have to account for the possibility that the module may update 
> from underneath my app, and I have to handle an unknown case. This is 
> simple: the compiler should require me to add a “default:” case to my 
> switch statement. This warning is produced IFF: the enum is coming from 
> an external module, and the enum is not decorated with @frozen.
 
 This does not help people who need to write a switch statement over an 
 enum vended by a module that ships with the OS keep their code up to date 
 as the module adds new cases. I find the example of 
 `SKPaymentTransactionState` provided by Brent Royal-Gordon here: 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
  
 
  to be compelling.  There are rare but legitimate reasons to switch over 
 all known cases of a non-@frozen enum that ship with the OS.  These use 
 cases deserve proper language support.  I think Jordan’s solution strikes 
 a good balance.
>>> 
>>> I disagree that more is needed. In the case of the transaction state, it 
>>> should not be marked as @moana, and so the compiler would force you to add 
>>> a “default” case to your switch statements. The switch statements would 
>>> still be exhaustive with all known cases (if you choose to handle all known 
>>> cases), but you’d still need a default case because there might be new 
>>> transaction states in the future.
>> 
>> And then you don't get the compiler error/warning when you start compiling 
>> against the next OS update that changes the enum. That is an absolutely 
>> unacceptable loss of compile-time checks.
> 
> Ah, that’s an excellent point! Thanks for pointing that out.
> 
> In that case, I revise my proposal:
> 
> 1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on 
> externally-linked modules
> 2️⃣ a “future case:” statement that’s only required on externally-linked, 
> non-@moana enums. That way, if the enum adds a new case in the future, you’ll 
> still get a switch warning about handling all the cases. And then if you 
> want, you could “fallthrough” from this to a “default” case, or vice-versa, 
> or have separate implementations.

It sounds to me like the main thing you’re unhappy about is having to deal with 
unknown cases when you have a source dependency that you always build and ship 
with an app.  I don’t think anyone is happy with that situation.  Did you take 
a look at the sketch of a solution provided by John McCall?  
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html
 

> 
> Dave
> 
>> 
>>> 
>>> In those cases, your app could decide what to do, if that’s possible at 
>>> all. Maybe there’s other transaction information you could introspect to 
>>> determine if it succeeded or is still pending or whatever, and then your 
>>> app could respond as you see fit.
>>> 
>>> Dave
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 3, 2018, at 11:49 AM, Dave DeLong  wrote:
> 
> 
> 
>> On Jan 3, 2018, at 10:36 AM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> IMO this is still too large of a hammer for this problem.
>>> 
>>> This whole “unexpected case” thing is only a problem when you’re linking 
>>> libraries that are external to/shipped independently of your app. Right 
>>> now, the *only* case where this might exist is Swift on the server. We 
>>> *might* run in to this in the future once the ABI stabilizes and we have 
>>> the Swift libraries shipping as part of iOS/macOS/Linux. Other than this, 
>>> unexpected enum cases won’t really be a problem developers have to deal 
>>> with.
>>> 
>>> Because this will be such a relatively rare problem, I feel like a syntax 
>>> change like what’s being proposed is a too-massive hammer for such a small 
>>> nail.
>>> 
>>> What feels far more appropriate is:
>>> 
>>> 🅰️ Teaching the compiler/checker/whatever about the linking semantics of 
>>> modules. For modules that are packaged inside the final built product, 
>>> there is no need to deal with any unexpected cases, because we already have 
>>> the exhaustiveness check appropriate for that scenario (regardless of 
>>> whether the module is shipped as a binary or compiled from source). The app 
>>> author decides when to update their dependencies, and updating those 
>>> dependencies will produce new warnings/errors as the compiler notices new 
>>> or deprecated cases. This is the current state of things and is completely 
>>> orthogonal to the entire discussion.
>> 
>> John McCall sketched out a vision of what a solution to this might look like 
>> here: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html
>>  
>> .
>>  
>> 
>>> 
>>> and
>>> 
>>> 🅱️ Adding an attribute (@frozen, @tangled, @moana, @whatever) that can be 
>>> used to decorate an enum declaration. This attribute would only need to be 
>>> consulted on enums where the compiler can determine that the module will 
>>> *not* be part of the final built product. (Ie, it’s an “external” module, 
>>> in my nomenclature). This, then, is a module that can update independently 
>>> of the final app, and therefore there are two possible cases:
>>> 
>>> 1️⃣ If the enum is decorated with @frozen, then I, as an app author, 
>>> have the assurance that the enum case will not change in future releases of 
>>> the library, and I can safely switch on all known cases and not have to 
>>> provide a default case. 
>>> 
>>> 2️⃣ If the enum is NOT decorated with @frozen, then I, as an app 
>>> author, have to account for the possibility that the module may update from 
>>> underneath my app, and I have to handle an unknown case. This is simple: 
>>> the compiler should require me to add a “default:” case to my switch 
>>> statement. This warning is produced IFF: the enum is coming from an 
>>> external module, and the enum is not decorated with @frozen.
>> 
>> This does not help people who need to write a switch statement over an enum 
>> vended by a module that ships with the OS keep their code up to date as the 
>> module adds new cases. I find the example of `SKPaymentTransactionState` 
>> provided by Brent Royal-Gordon here: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
>>  
>> 
>>  to be compelling.  There are rare but legitimate reasons to switch over all 
>> known cases of a non-@frozen enum that ship with the OS.  These use cases 
>> deserve proper language support.  I think Jordan’s solution strikes a good 
>> balance.
> 
> I disagree that more is needed. In the case of the transaction state, it 
> should not be marked as @moana, and so the compiler would force you to add a 
> “default” case to your switch statements. The switch statements would still 
> be exhaustive with all known cases (if you choose to handle all known cases), 
> but you’d still need a default case because there might be new transaction 
> states in the future.
> 
> In those cases, your app could decide what to do, if that’s possible at all. 
> Maybe there’s other transaction information you could introspect to determine 
> if it succeeded or is still pending or whatever, and then your app could 
> respond as you see fit.

SKPaymentTransactionState is an excellent motivating example for a better 
solution because it is crucial to update code to handle any new states 
accurately and promptly.  This is much easier to do with compiler assistance 
than without it. 

It is also an excellent motivating example because the API change is driven by 
a business change and for which all states should be reflected accurately in 
the UX.

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

[Dave DeLong via swift-evolution]

> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger  wrote:
> 
 [...]
2️⃣ If the enum is NOT decorated with @frozen, then I, as an app 
 author, have to account for the possibility that the module may update 
 from underneath my app, and I have to handle an unknown case. This is 
 simple: the compiler should require me to add a “default:” case to my 
 switch statement. This warning is produced IFF: the enum is coming from an 
 external module, and the enum is not decorated with @frozen.
>>> 
>>> This does not help people who need to write a switch statement over an enum 
>>> vended by a module that ships with the OS keep their code up to date as the 
>>> module adds new cases. I find the example of `SKPaymentTransactionState` 
>>> provided by Brent Royal-Gordon here: 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
>>>  
>>> 
>>>  to be compelling.  There are rare but legitimate reasons to switch over 
>>> all known cases of a non-@frozen enum that ship with the OS.  These use 
>>> cases deserve proper language support.  I think Jordan’s solution strikes a 
>>> good balance.
>> 
>> I disagree that more is needed. In the case of the transaction state, it 
>> should not be marked as @moana, and so the compiler would force you to add a 
>> “default” case to your switch statements. The switch statements would still 
>> be exhaustive with all known cases (if you choose to handle all known 
>> cases), but you’d still need a default case because there might be new 
>> transaction states in the future.
> 
> And then you don't get the compiler error/warning when you start compiling 
> against the next OS update that changes the enum. That is an absolutely 
> unacceptable loss of compile-time checks.

Ah, that’s an excellent point! Thanks for pointing that out.

In that case, I revise my proposal:

1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on 
externally-linked modules
2️⃣ a “future case:” statement that’s only required on externally-linked, 
non-@moana enums. That way, if the enum adds a new case in the future, you’ll 
still get a switch warning about handling all the cases. And then if you want, 
you could “fallthrough” from this to a “default” case, or vice-versa, or have 
separate implementations.

Dave

> 
>> 
>> In those cases, your app could decide what to do, if that’s possible at all. 
>> Maybe there’s other transaction information you could introspect to 
>> determine if it succeeded or is still pending or whatever, and then your app 
>> could respond as you see fit.
>> 
>> Dave
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Nattinger via swift-evolution]

>>> [...]
>>> 2️⃣ If the enum is NOT decorated with @frozen, then I, as an app 
>>> author, have to account for the possibility that the module may update from 
>>> underneath my app, and I have to handle an unknown case. This is simple: 
>>> the compiler should require me to add a “default:” case to my switch 
>>> statement. This warning is produced IFF: the enum is coming from an 
>>> external module, and the enum is not decorated with @frozen.
>> 
>> This does not help people who need to write a switch statement over an enum 
>> vended by a module that ships with the OS keep their code up to date as the 
>> module adds new cases. I find the example of `SKPaymentTransactionState` 
>> provided by Brent Royal-Gordon here: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
>>  
>> 
>>  to be compelling.  There are rare but legitimate reasons to switch over all 
>> known cases of a non-@frozen enum that ship with the OS.  These use cases 
>> deserve proper language support.  I think Jordan’s solution strikes a good 
>> balance.
> 
> I disagree that more is needed. In the case of the transaction state, it 
> should not be marked as @moana, and so the compiler would force you to add a 
> “default” case to your switch statements. The switch statements would still 
> be exhaustive with all known cases (if you choose to handle all known cases), 
> but you’d still need a default case because there might be new transaction 
> states in the future.

And then you don't get the compiler error/warning when you start compiling 
against the next OS update that changes the enum. That is an absolutely 
unacceptable loss of compile-time checks.

> 
> In those cases, your app could decide what to do, if that’s possible at all. 
> Maybe there’s other transaction information you could introspect to determine 
> if it succeeded or is still pending or whatever, and then your app could 
> respond as you see fit.
> 
> Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 3, 2018, at 11:47 AM, BJ Homer  wrote:
> 
> 
> 
>> On Jan 3, 2018, at 10:36 AM, Matthew Johnson via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> This does not help people who need to write a switch statement over an enum 
>> vended by a module that ships with the OS keep their code up to date as the 
>> module adds new cases. I find the example of `SKPaymentTransactionState` 
>> provided by Brent Royal-Gordon here: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
>>  
>> 
>>  to be compelling.  There are rare but legitimate reasons to switch over all 
>> known cases of a non-@frozen enum that ship with the OS.  These use cases 
>> deserve proper language support.  I think Jordan’s solution strikes a good 
>> balance.
> 
> I agree that the SKPaymentTransactionState example is compelling. However, I 
> don’t understand what actual code a developer would put in the “unexpected 
> case:” clause. That enum is related to handling in-app purchases; it’s 
> expected that the app would react in some way to a transaction changing 
> state. What should the app do if the transaction enters an “unexpected” 
> state? Pop up an error to the user that the user can do nothing about? It’s 
> great to get a compiler warning about a case like when the developer builds 
> with the new SDK, but I don’t understand what the already-shipped app is 
> supposed to do in a case like this.
> 
> For the SKPaymentTransactionState case, at least, it seems like the library 
> needs to be responsible to only send known values to the client. Otherwise, 
> the app can have no idea what to do.

There is definitely not a good answer here.  Making the library responsible to 
only send known values is not a solution.  This type represents the state of an 
entity and it should do so as accurately as possible.  Sometimes a new state 
cannot be mapped to one of the previous states.  How would you have StoreKit 
handle the deferred state for old clients?

My position is that the situation is much worse for an app developer when they 
don’t even get the assistance of a compiler warning when updating to the new 
SDK.  App developers are sometimes forced to deal with unfortunate cases like 
this.  Any help the language can provide is appreciated.

> 
> -BJ

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave DeLong via swift-evolution]

> On Jan 3, 2018, at 10:36 AM, Matthew Johnson  wrote:
> 
> 
>> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> IMO this is still too large of a hammer for this problem.
>> 
>> This whole “unexpected case” thing is only a problem when you’re linking 
>> libraries that are external to/shipped independently of your app. Right now, 
>> the *only* case where this might exist is Swift on the server. We *might* 
>> run in to this in the future once the ABI stabilizes and we have the Swift 
>> libraries shipping as part of iOS/macOS/Linux. Other than this, unexpected 
>> enum cases won’t really be a problem developers have to deal with.
>> 
>> Because this will be such a relatively rare problem, I feel like a syntax 
>> change like what’s being proposed is a too-massive hammer for such a small 
>> nail.
>> 
>> What feels far more appropriate is:
>> 
>> 🅰️ Teaching the compiler/checker/whatever about the linking semantics of 
>> modules. For modules that are packaged inside the final built product, there 
>> is no need to deal with any unexpected cases, because we already have the 
>> exhaustiveness check appropriate for that scenario (regardless of whether 
>> the module is shipped as a binary or compiled from source). The app author 
>> decides when to update their dependencies, and updating those dependencies 
>> will produce new warnings/errors as the compiler notices new or deprecated 
>> cases. This is the current state of things and is completely orthogonal to 
>> the entire discussion.
> 
> John McCall sketched out a vision of what a solution to this might look like 
> here: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html
>  
> .
>  
> 
>> 
>> and
>> 
>> 🅱️ Adding an attribute (@frozen, @tangled, @moana, @whatever) that can be 
>> used to decorate an enum declaration. This attribute would only need to be 
>> consulted on enums where the compiler can determine that the module will 
>> *not* be part of the final built product. (Ie, it’s an “external” module, in 
>> my nomenclature). This, then, is a module that can update independently of 
>> the final app, and therefore there are two possible cases:
>> 
>>  1️⃣ If the enum is decorated with @frozen, then I, as an app author, 
>> have the assurance that the enum case will not change in future releases of 
>> the library, and I can safely switch on all known cases and not have to 
>> provide a default case. 
>> 
>>  2️⃣ If the enum is NOT decorated with @frozen, then I, as an app 
>> author, have to account for the possibility that the module may update from 
>> underneath my app, and I have to handle an unknown case. This is simple: the 
>> compiler should require me to add a “default:” case to my switch statement. 
>> This warning is produced IFF: the enum is coming from an external module, 
>> and the enum is not decorated with @frozen.
> 
> This does not help people who need to write a switch statement over an enum 
> vended by a module that ships with the OS keep their code up to date as the 
> module adds new cases. I find the example of `SKPaymentTransactionState` 
> provided by Brent Royal-Gordon here: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
>  
> 
>  to be compelling.  There are rare but legitimate reasons to switch over all 
> known cases of a non-@frozen enum that ship with the OS.  These use cases 
> deserve proper language support.  I think Jordan’s solution strikes a good 
> balance.

I disagree that more is needed. In the case of the transaction state, it should 
not be marked as @moana, and so the compiler would force you to add a “default” 
case to your switch statements. The switch statements would still be exhaustive 
with all known cases (if you choose to handle all known cases), but you’d still 
need a default case because there might be new transaction states in the future.

In those cases, your app could decide what to do, if that’s possible at all. 
Maybe there’s other transaction information you could introspect to determine 
if it succeeded or is still pending or whatever, and then your app could 
respond as you see fit.

Dave___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[BJ Homer via swift-evolution]

> On Jan 3, 2018, at 10:36 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> This does not help people who need to write a switch statement over an enum 
> vended by a module that ships with the OS keep their code up to date as the 
> module adds new cases. I find the example of `SKPaymentTransactionState` 
> provided by Brent Royal-Gordon here: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
>  
> 
>  to be compelling.  There are rare but legitimate reasons to switch over all 
> known cases of a non-@frozen enum that ship with the OS.  These use cases 
> deserve proper language support.  I think Jordan’s solution strikes a good 
> balance.

I agree that the SKPaymentTransactionState example is compelling. However, I 
don’t understand what actual code a developer would put in the “unexpected 
case:” clause. That enum is related to handling in-app purchases; it’s expected 
that the app would react in some way to a transaction changing state. What 
should the app do if the transaction enters an “unexpected” state? Pop up an 
error to the user that the user can do nothing about? It’s great to get a 
compiler warning about a case like when the developer builds with the new SDK, 
but I don’t understand what the already-shipped app is supposed to do in a case 
like this.

For the SKPaymentTransactionState case, at least, it seems like the library 
needs to be responsible to only send known values to the client. Otherwise, the 
app can have no idea what to do.

-BJ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution 
>  wrote:
> 
> IMO this is still too large of a hammer for this problem.
> 
> This whole “unexpected case” thing is only a problem when you’re linking 
> libraries that are external to/shipped independently of your app. Right now, 
> the *only* case where this might exist is Swift on the server. We *might* run 
> in to this in the future once the ABI stabilizes and we have the Swift 
> libraries shipping as part of iOS/macOS/Linux. Other than this, unexpected 
> enum cases won’t really be a problem developers have to deal with.
> 
> Because this will be such a relatively rare problem, I feel like a syntax 
> change like what’s being proposed is a too-massive hammer for such a small 
> nail.
> 
> What feels far more appropriate is:
> 
> 🅰️ Teaching the compiler/checker/whatever about the linking semantics of 
> modules. For modules that are packaged inside the final built product, there 
> is no need to deal with any unexpected cases, because we already have the 
> exhaustiveness check appropriate for that scenario (regardless of whether the 
> module is shipped as a binary or compiled from source). The app author 
> decides when to update their dependencies, and updating those dependencies 
> will produce new warnings/errors as the compiler notices new or deprecated 
> cases. This is the current state of things and is completely orthogonal to 
> the entire discussion.

John McCall sketched out a vision of what a solution to this might look like 
here: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html
 
.
 

> 
> and
> 
> 🅱️ Adding an attribute (@frozen, @tangled, @moana, @whatever) that can be 
> used to decorate an enum declaration. This attribute would only need to be 
> consulted on enums where the compiler can determine that the module will 
> *not* be part of the final built product. (Ie, it’s an “external” module, in 
> my nomenclature). This, then, is a module that can update independently of 
> the final app, and therefore there are two possible cases:
> 
>   1️⃣ If the enum is decorated with @frozen, then I, as an app author, 
> have the assurance that the enum case will not change in future releases of 
> the library, and I can safely switch on all known cases and not have to 
> provide a default case. 
> 
>   2️⃣ If the enum is NOT decorated with @frozen, then I, as an app 
> author, have to account for the possibility that the module may update from 
> underneath my app, and I have to handle an unknown case. This is simple: the 
> compiler should require me to add a “default:” case to my switch statement. 
> This warning is produced IFF: the enum is coming from an external module, and 
> the enum is not decorated with @frozen.

This does not help people who need to write a switch statement over an enum 
vended by a module that ships with the OS keep their code up to date as the 
module adds new cases. I find the example of `SKPaymentTransactionState` 
provided by Brent Royal-Gordon here: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
 

 to be compelling.  There are rare but legitimate reasons to switch over all 
known cases of a non-@frozen enum that ship with the OS.  These use cases 
deserve proper language support.  I think Jordan’s solution strikes a good 
balance.

> 
> 
> ==
> 
> With this proposal, we only have one thing to consider: the spelling of 
> @frozen/@moana/@whatever that we decorate enums in external modules with. 
> Other than that, the existing behavior we currently have is completely 
> capable of covering the possibilities: we just keep using a “default:” case 
> whenever the compiler can’t guarantee that we can be exhaustive in our 
> switching.
> 
> Where the real work would be is teaching the compiler about 
> internally-vs-externally linked modules.
> 
> Dave
> 
>> On Jan 2, 2018, at 7: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
>>  
>> ]
>> 
>> Whew! Thanks for your feedback, everyone. On the lighter side of 
>> feedback—naming things—it seems that most people seem to like '@frozen', and 
>> that does in fact have the connotations we want it to have. I like it too.
>> 
>> More seriously, this discussion has convinced me that it's worth including 
>> what the proposal discusses as a 'future' case. The key point that swayed me 
>> is that this can produce a warning when the switch is missing a case rather 
>> than an error, which both provides the necessary compiler feedback to update 
>> your code and allows yo

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

[Ben Rimmington via swift-evolution]

> On 3 Jan 2018, at 02:07, Jordan Rose 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 things—it seems that most people seem to like '@frozen', and 
> that does in fact have the connotations we want it to have. I like it too.

Should there be a new Clang attribute for "frozen" enums? Then the existing 
`__attribute__((enum_extensibility(closed)))` would only prevent "private" 
cases (and not future "public" cases).



> More seriously, this discussion has convinced me that it's worth including 
> what the proposal discusses as a 'future' case. The key point that swayed me 
> is that this can produce a warning when the switch is missing a case rather 
> than an error, which both provides the necessary compiler feedback to update 
> your code and allows your dependencies to continue compiling when you update 
> to a newer SDK. I know people on both sides won't be 100% satisfied with 
> this, but does it seem like a reasonable compromise?
> 
> The next question is how to spell it. I'm leaning towards `unexpected case:`, 
> which (a) is backwards-compatible, and (b) also handles "private cases", 
> either the fake kind that you can do in C (as described in the proposal), or 
> some real feature we might add to Swift some day. `unknown case:` isn't bad 
> either.

You might end up with `case .unknown:` and `unknown case:` in the same switch.

e.g. 

```
switch mediaType {
case .image, .video, .audio:
break
case .unknown:
break
unknown case:
break
}
```

-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave DeLong via swift-evolution]

IMO this is still too large of a hammer for this problem.

This whole “unexpected case” thing is only a problem when you’re linking 
libraries that are external to/shipped independently of your app. Right now, 
the *only* case where this might exist is Swift on the server. We *might* run 
in to this in the future once the ABI stabilizes and we have the Swift 
libraries shipping as part of iOS/macOS/Linux. Other than this, unexpected enum 
cases won’t really be a problem developers have to deal with.

Because this will be such a relatively rare problem, I feel like a syntax 
change like what’s being proposed is a too-massive hammer for such a small nail.

What feels far more appropriate is:

🅰️ Teaching the compiler/checker/whatever about the linking semantics of 
modules. For modules that are packaged inside the final built product, there is 
no need to deal with any unexpected cases, because we already have the 
exhaustiveness check appropriate for that scenario (regardless of whether the 
module is shipped as a binary or compiled from source). The app author decides 
when to update their dependencies, and updating those dependencies will produce 
new warnings/errors as the compiler notices new or deprecated cases. This is 
the current state of things and is completely orthogonal to the entire 
discussion.

and

🅱️ Adding an attribute (@frozen, @tangled, @moana, @whatever) that can be used 
to decorate an enum declaration. This attribute would only need to be consulted 
on enums where the compiler can determine that the module will *not* be part of 
the final built product. (Ie, it’s an “external” module, in my nomenclature). 
This, then, is a module that can update independently of the final app, and 
therefore there are two possible cases:

1️⃣ If the enum is decorated with @frozen, then I, as an app author, 
have the assurance that the enum case will not change in future releases of the 
library, and I can safely switch on all known cases and not have to provide a 
default case. 

2️⃣ If the enum is NOT decorated with @frozen, then I, as an app 
author, have to account for the possibility that the module may update from 
underneath my app, and I have to handle an unknown case. This is simple: the 
compiler should require me to add a “default:” case to my switch statement. 
This warning is produced IFF: the enum is coming from an external module, and 
the enum is not decorated with @frozen.


==

With this proposal, we only have one thing to consider: the spelling of 
@frozen/@moana/@whatever that we decorate enums in external modules with. Other 
than that, the existing behavior we currently have is completely capable of 
covering the possibilities: we just keep using a “default:” case whenever the 
compiler can’t guarantee that we can be exhaustive in our switching.

Where the real work would be is teaching the compiler about 
internally-vs-externally linked modules.

Dave

> On Jan 2, 2018, at 7:07 PM, 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 feedback, everyone. On the lighter side of 
> feedback—naming things—it seems that most people seem to like '@frozen', and 
> that does in fact have the connotations we want it to have. I like it too.
> 
> More seriously, this discussion has convinced me that it's worth including 
> what the proposal discusses as a 'future' case. The key point that swayed me 
> is that this can produce a warning when the switch is missing a case rather 
> than an error, which both provides the necessary compiler feedback to update 
> your code and allows your dependencies to continue compiling when you update 
> to a newer SDK. I know people on both sides won't be 100% satisfied with 
> this, but does it seem like a reasonable compromise?
> 
> The next question is how to spell it. I'm leaning towards `unexpected case:`, 
> which (a) is backwards-compatible, and (b) also handles "private cases", 
> either the fake kind that you can do in C (as described in the proposal), or 
> some real feature we might add to Swift some day. `unknown case:` isn't bad 
> either.
> 
> I too would like to just do `unknown:` or `unexpected:` but that's 
> technically a source-breaking change:
> 
> switch foo {
> case bar:
>   unknown:
>   while baz() {
> while garply() {
>   if quux() {
> break unknown
>   }
> }
>   }
> }
> 
> Another downside of the `unexpected case:` spelling is that it doesn't work 
> as part of a larger pattern. I don't have a good answer for that one, but 
> perhaps it's acceptable for now.
> 
> I'll write up a revision of the proposal soon and make sure the core team 
> gets my recommendation when they discuss the results of the review.
> 
> ---
> 
> I'll respond to a few of the more intricate

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

[Dave DeLong via swift-evolution]

> On Jan 2, 2018, at 10:26 PM, Kelvin Ma via swift-evolution 
>  wrote:
> 
> 
> 
> On Tue, Jan 2, 2018 at 11:45 PM, Nevin Brackett-Rozinsky via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> On Tue, Jan 2, 2018 at 9: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
>  
> ]
> 
> Whew! Thanks for your feedback, everyone. On the lighter side of 
> feedback—naming things—it seems that most people seem to like '@frozen', and 
> that does in fact have the connotations we want it to have. I like it too.
> 
> More seriously, this discussion has convinced me that it's worth including 
> what the proposal discusses as a 'future' case. The key point that swayed me 
> is that this can produce a warning when the switch is missing a case rather 
> than an error, which both provides the necessary compiler feedback to update 
> your code and allows your dependencies to continue compiling when you update 
> to a newer SDK. I know people on both sides won't be 100% satisfied with 
> this, but does it seem like a reasonable compromise?
> 
> The next question is how to spell it. I'm leaning towards `unexpected case:`, 
> which (a) is backwards-compatible, and (b) also handles "private cases", 
> either the fake kind that you can do in C (as described in the proposal), or 
> some real feature we might add to Swift some day. `unknown case:` isn't bad 
> either.
> 
> I too would like to just do `unknown:` or `unexpected:` but that's 
> technically a source-breaking change:
> 
> switch foo {
> case bar:
>   unknown:
>   while baz() {
> while garply() {
>   if quux() {
> break unknown
>   }
> }
>   }
> }
> 
> Another downside of the `unexpected case:` spelling is that it doesn't work 
> as part of a larger pattern. I don't have a good answer for that one, but 
> perhaps it's acceptable for now.
> 
> I'll write up a revision of the proposal soon and make sure the core team 
> gets my recommendation when they discuss the results of the review.
> 
> ---
> 
> I'll respond to a few of the more intricate discussions tomorrow, including 
> the syntax of putting a new declaration inside the enum rather than outside. 
> Thank you again, everyone, and happy new year!
> 
> Jordan
> 
> 
> +1 to warning instead of error
> +1 to unknown/unexpected case
> +1 to “@frozen” or any other reasonable spelling, they are all fine by me.
> 
> +1 to “@tangled” because abi is complicated

+1 to “@moana” because these are all just Disney movies

>  
> 
> The one remaining problem to solve is making sure multi-module apps can leave 
> out the unknown/unexpected case on enums from modules which are part of the 
> app itself and thus cannot be updated independently of it. John McCall’s 
> version-locking plan sounds promising, though we should explore the available 
> options before finalizing a course.
> 
> Perhaps we need a concept of submodules, or supermodules, or some other way 
> to demarcate the boundaries of a resilience domain.
> 
> Nevin
> 
> i would support a proper submodule system over some verson-locking system 
> that only the most advanced users will probably know about. i think modules 
> should be one level higher than what they’re currently being used for right 
> now for lack of a better alternative (one application should never have to 
> define more than one capital M Module). submodules shouldn’t be that hard to 
> implement, though the submodule names should be part of ABI to avoid name 
> mangling problems
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Howard Lovatt via swift-evolution]

Despite having suggested the @version syntax I do agree with people that have 
said any @annotation is both a burden on the programmer and severely reduces 
readability. 

Therefore a 4th option, carrying on from the numbering in my previous email is:

  4. The compiler issues a description of the public enums in a module. 
Application code that uses the enums knows what version of the enum they were 
compiled against. When the application launches the runtime writes a 
translation between the module enum and the application enum and vice versa. 
When an enum goes into or comes out of the application code to/from the module 
code it goes through the translation functions. EG:

// Module version 1. 
public enum E {
case A, B, C
}
...
switch e {
case A: a()
default: d() // Could alternatively have cases B and C instead of default. 
unknown case: u() // Must have unknown case for a public enum. 
}

// Application code compiled against module version 1. 
// Stored in the code is the description of E having cases A, B, and C. 
switch e {
case A: a()
default: d() // Could alternatively have cases B and C instead of default. 
unknown case: u() // Must have unknown case for a public enum. 
}

The translation functions in each direction are trivial since the two enums 
match and therefore have the same numbering and the same number range. 

Now the module is changed. 

// Module version 2.
public enum E {
case A, C, D // B deleted and D added. 
}
...
// switch as before but now D calls d() and B calls u(). Previously B 
called d() but since B is deleted it is now an unknown case. 

The translation between module 2 code and application compiled against 1 code 
is:

  Module 2 <—> Application 1
  A   <—> A
  U   <—   B
  C   <—> C
  D —> U

IE all the old cases, from the application, are translated into unknown on the 
module side and all the new cases, from the module, are translated to unknown 
on the application side. 

This way neither the module programmer nor the application programmer has to 
version their code since the runtime provides the translation. 

It is source breaking however, since all switches of public enums require an 
unknown case both in the module code and application code. 

-- Howard. 

> On 3 Jan 2018, at 3:54 am, Jason Merchant via swift-evolution 
>  wrote:
> 
> Is it hard to imagine that most everyone can get what they want and keep the 
> syntax clean and streamlined at the same time? Without any "@" signs or other 
> compiler hints?
> 
>> "Rather, we are how to enable the vendor of a nonexhaustive enum to add new 
>> cases without breaking binaries compiled against previous versions"
> 
> When an enum changes, and the change causes the code to break, the user can 
> be presented with migration options from an automated IDE tool. In what 
> specific way does this not solve the issue about having to upgrade your code 
> when using someone else's code library? This very notion implies your 
> disgruntled about doing work when things are upgraded, is that really what 
> this fuss is all about?
> 
> A well written language interpreter and auto-tooling IDE would not need hints 
> embedded in the code syntax itself. Migration hints from version to version 
> should not be a part of either the past or future version of the code library.
> 
> ...
> 
> I don't expect the community to agree on language grammar, but the common 
> sense here on how to achieve the intended goals seems to be out of wack.
> 
> If someone can present a clear logical statement as to how an automated 
> migration tool behind the scenes in the IDE to handle all your versioning 
> worries, does not make this whole discussion about adding more convoluted 
> syntax additions irrelevant, I'd love to hear it.
> 
> ___
> 
> Sincerely,
> Jason
> 
> 
> 
> 
> 
> 
>> On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu  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.
>>> 
>>> 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) Add new things to the list of choices in the future as they come up with 
>>> new ideas
>>> B) Sometimes select one of the choices to be chosen as the normal choice if 
>>> no choice is made by the user
>>> 
>>> A and B are separate desires. In some circumstances a developer may want to 
>>> add a new choice and make it the normal choice when there was no normal 
>>> choice was clarified before.
>> 
>> I don't think this is an accurate summary of the problem being tackled here. 
>> Rather, we are how to enable the vendor of a nonex

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

[Jason Merchant via swift-evolution]

Is it hard to imagine that most everyone can get what they want and keep
the syntax clean and streamlined at the same time? Without any "@" signs or
other compiler hints?

"Rather, we are how to enable the vendor of a nonexhaustive enum to add new
> cases without breaking binaries compiled against previous versions"


When an enum changes, and the change causes the code to break, the user can
be presented with migration options from an automated IDE tool. In what
specific way does this not solve the issue about having to upgrade your
code when using someone else's code library? This very notion implies your
disgruntled about doing work when things are upgraded, is that really what
this fuss is all about?

A well written language interpreter and auto-tooling IDE would not need
hints embedded in the code syntax itself. Migration hints from version to
version should not be a part of either the past or future version of the
code library.

...

I don't expect the community to agree on language grammar, but the common
sense here on how to achieve the intended goals seems to be out of wack.

If someone can present a clear logical statement as to how an automated
migration tool behind the scenes in the IDE to handle all your versioning
worries, does not make this whole discussion about adding more convoluted
syntax additions irrelevant, I'd love to hear it.

___

Sincerely,
Jason






On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu  wrote:

> 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 follows:
>>
>> *A list of something is desired:*
>> 1 - Pancake
>> 2 - Waffle
>> 3 - Juice
>>
>> *Developer wishes to be able to:*
>> *A)* Add new things to the list of choices in the future as they come up
>> with new ideas
>> *B)* Sometimes select one of the choices to be chosen as the normal
>> choice if no choice is made by the user
>>
>> A and B are *separate desires*. In some circumstances a developer may
>> want to add a new choice and make it the normal choice when there was no
>> normal choice was clarified before.
>>
>
> I don't think this is an accurate summary of the problem being tackled
> here. Rather, we are how to enable the vendor of a nonexhaustive enum to
> add new cases without breaking binaries compiled against previous versions.
> There is little here to do with what a "default" should be. Indeed, it is
> an explicit design decision of Swift not to support types having an
> implicit default value.
>
>
>> 
>>
>> *Part 2:*
>>
>> After this simple desire is clear, there should be two discussions:
>> *A)* In a text only coding language, what would we like the syntax to
>> look like? (Without regard to past-bias. What should it really be, forget
>> what mistaken design choices were made in Swift in the past)
>> *B)* How do we approach making this happen behind the scenes?
>>
>> *Bonus:* Given that some of us have changed our approach to programming
>> significantly beyond text based coding, and into more dynamic mediums of
>> programming in other niches, and even here and there in Xcode - I would
>> recommend considering how the IDE would show a modern version of this
>> concept. I feel too often that Swift design syntax has a *lack of
>> awareness between the distinctions of what the IDE should do, as opposed to
>> what the syntax of the language should be*, and what should be handled
>> behind the scenes by automated tooling.
>>
>> _
>>
>> *My opinion*, in answering the above questions is in preference to a
>> simple easy to read and write syntax, something like the following:
>>
>> choices Breakfast {
>> Pancake, *Waffle*, Juice
>> }
>>
>> If a "default" choice is desired, it is obvious to me that I would select
>> the choice from the IDE, and it would be visually indicated that it was the
>> default.
>>
>> When changes occur, whether new choices are added, old ones are removed
>> or changed, or a default is added, changed, or removed - a behind the
>> scenes automated tool analyzes the changes and presents migration options
>> through the IDE.
>>
>> _
>>
>> Sincerely,
>> Jason
>>
>>
>>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution