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

[Riley Testut]

-1.

I agree this is a problem, but I think this is the wrong solution. I think the solution should be on the client side, not on the framework author’s side.

I would be fine if enums from imported modules are non-exhaustive, as long as I can choose to treat them as exhaustive if I want to. And in that case, if a new case is introduced, I think a fatal error is a reasonable result.

The proposed “switch!” command would do just this, and I think that is the better answer for this. Adding an @exhaustive attribute doesn’t actually prevent someone from adding a case anyway, which I think is a big (and not really solvable) issue 🤷‍♂️

I know much has been said about this, but it’s just my 2c.

> On Dec 27, 2017, at 9:42 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>> What is your evaluation of the proposal?
>> 
> 
> -1
> 
> I would much prefer the solution proposed by Andrew Bennett in another thread which solves all problems very nicely including the testability of future cases by giving them a placeholder name:
> 
> From Andrew’s mail:
>> public enum HomeworkExcuse {
>>   case eatenByPet
>>   case thoughtItWasDueNextWeek
>>   fallback unknown // NEW
>> }
>> 
>> Then I believe you would be able to have an exhaustive switch like this:
>> 
>> switch thing {
>>   case eatenByPet: break
>>   case thoughtItWasDueNextWeek: break
>>   case unknown: break
>> }
>> 
>> Which would still allow compile-time errors if new cases are introduced, while providing a concise way to show something is not exhaustible.
>> 
>> This would also support existing enums with "unknown" equivalent cases would be able to explicitly label those fields as fallback without needing to make large code changes.
>> 
>> I see no reason why you shouldn't be able to use ".unknown", which should still allow this to be testable.
> 
> i.e. Andrew’s idea is to introduce a placeholder case instead of marking the enum as exhaustive/non-exhaustive. This gives the future cases a handle to be switched on and to be tested against. Very elegant.
> 
>> Is the problem being addressed significant enough to warrant a change to Swift?
>> 
> Yes, but the proposed solution is not as good as it should be, neglecting to provide compile-time errors if new cases are introduced.
>> Does this proposal fit well with the feel and direction of Swift?
>> 
> No, due to its shortcomings.
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> 
> None, but see Andrew Bennett’s idea above.
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
> Followed most of the discussion and review threads.
> 
> -Thorsten
> _______________________________________________
> 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/20171228/14f8d9d1/attachment.html>