[swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

[Cheyo Jimenez]

> On Dec 23, 2017, at 4:15 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Dec 23, 2017, at 3:47 PM, Thomas Roughton via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> What are your thoughts on `final switch` as a way to treat any enum as exhaustible?
>>> https://dlang.org/spec/statement.html#FinalSwitchStatement
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> I’d be very much in favour of this (qualms about the naming of the ‘final’ keyword aside - ‘complete’ or ‘exhaustive’ reads better to me). 
>> 
>> Looking back at the proposal, I noticed that something similar was mentioned that I earlier missed. In the proposal, it says:
>> 
>>> However, this results in some of your code being impossible to test, since you can't write a test that passes an unknown value to this switch.
>> 
>> Is that strictly true? Would it be theoretically possible for the compiler to emit or make accessible a special ‘test’ case for non-exhaustive enums that can only be used in test modules or e.g. by a ‘EnumName(testCaseNamed:)’, constructor? There is  potential for abuse there but it would address that particular issue. 
>> 
>> Regardless, I still feel something like a ‘final switch’ is necessary if this proposal is introduced, and that it fits with the ‘progressive disclosure’ notion; once you learn this keyword you have a means to check for completeness, but people unaware of it could just use a ‘default’ case as per usual and not be concerned with exhaustiveness checking. 
> 
> My general philosophy with syntax sugar is that it should do more than just remove a constant number of tokens. Basically you’re saying that
> 
> final switch x {}
> 
> just expands to
> 
> switch x { // edited
> default: fatalError()
> }
> 
> I don’t think a language construct like this carries its weight.

Having the ability to treat a non exhaustive enum as if it where exhaustive is not the same as 

switch x {
default : fatalError()
}

The above will happily let me omit currently compile time known cases.  Perhaps ‘final switch’ is not the best but I can’t think of another way to semantically “cast” a non exhaustive as exhaustive. Essentially what I believe we want is a way to treat a non exhaustive as exhaustive during compile time, on the client side. 

It would be cool if we instead repurposed the swift “case _” to handle all compile time known cases and default could then handle all unknown future cases in an non exhaustive enum. 

public enum x {a, b, c, d}

switch x { // x is non exhaustive here
  case a: print("case a")
  case _ : print(“known cases b c or d”) // sugar for cases b, c, d which are known during compile time. Expanded to mean case b, c, d. 
default: fatalError() // future unknown cases
}

I don’t think this would would break any code since all enums have been exhaustive. No new syntax would be added and now there would be a meaningful difference between compile time known cases (case _) vs compile time unknown future cases (default). 


> 
> For example, generics have a multiplicative effect on code size — they prevent you from having to write an arbitrary number of versions of the same algorithm for different concrete types.
> 
> Another example is optionals — while optionals don’t necessarily make code shorter, they make it more understandable, and having optionals in the language rules out entire classes of errors at compile time.
> 
> On the other hand, a language feature that just reduces the number of tokens without any second-order effects makes code harder to read, the language harder to learn, and the compiler buggier and harder to maintain without much benefit. So I think for the long term health of the language we should avoid ‘shortcuts’ like this.
> 
> Slava
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171223/02df71fe/attachment.html>