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

[Jonathan Hull]

> On Dec 21, 2017, at 11:07 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> Thanks for your comments, Jon. Responses inline.
> 
>> On Dec 20, 2017, at 12:46, Jonathan Hull <jhull at gbis.com <mailto:jhull at gbis.com>> wrote:
>> 
>> 
>>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> When reviewing a proposal, here are some questions to consider:
>>> 
>>> What is your evaluation of the proposal?
>>> 
>> Strong -1 as is.
>> 
>> I think I would support having an explicit ‘futureCase’ which is different from ‘default’.  Requiring default is asking for bugs.  With a separate ‘futureCase’, we would still get a compile-time error when all of the current cases aren’t handled.  Note that ‘ futureCase’ is also different than ‘default’ in that it wouldn’t have to go at the bottom.  It would only be triggered when the value isn’t one of the values which was known at compile time.  We should also bike shed the name of ‘futureCase’ to come up with something that might allow us to make other types of extendable enums….  Maybe something like ‘unknownCase’ or ‘unexpectedCase’.
>> 
>> As for the issue of testing, we could add (later) a universally unexpected case that non-exhaustive enums can be set to for testing. I am not convinced that this is actually a big enough issue to warrant that though. Forcing ‘default’ is a much larger real-world problem, IMO (and this use of ‘default’ is just as untestable).
> 
> Both of these are discussed in "Alternatives considered", and they have flaws that led me to leave them out of the proposal. Do you have any ideas on how to improve on that?

What are the flaws?  I saw that the ‘Future’ case can’t be tested… but using ‘default’ is just as untestable in the same way.  Others have given lots of examples where it will actually be used.

I think we should reframe it so that instead of talking about exhaustive vs. non-exhaustive, all switches need to be exhaustive… but switches over these enums need to handle unexpected cases to be considered exhaustive.

I know it is marked as an “alternative”, but it seems clear to me that having an ‘unexpected’ case (which only matches cases not known at compile time) is the clear answer here.  Something like 75% of  responses have mentioned it.


> 
>> 
>> I also dislike the name @exhaustive because I think it will cause confusion (i.e. “Of course my Enum is exhaustive”).  I think we should just have @fixed for both enums and structs. The word fixed has the connotation that it shouldn’t change.
> 
> I don't think anybody loves "exhaustive", but using the same attribute for enums and structs isn't really appropriate, as discussed in my response to Karl yesterday <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042248.html>. I'm not opposed to a better name if we can gravitate towards one, though.

I really like @frozen.  It has a much clearer connotation of what it means, and can be used for structs too.

Thanks,
Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171223/6d753f69/attachment.html>