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

[Riley Testut]

Actually, from the other email thread about this same topic (thank god forums are almost here), I see the proposed syntax “final switch” for what I referred to as “switch!”, which I prefer.

> On Dec 28, 2017, at 12:17 AM, Riley Testut via swift-evolution <swift-evolution at swift.org> wrote:
> 
> -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
> _______________________________________________
> 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/029537a8/attachment.html>