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

[Eneko Alonso]

Hello everyone, 

My name is Eneko Alonso, iOS developer, new here on the list.

Is there a good summary anywhere that condenses the pros and cons of this new feature that have been discussed so far?

It is not clear to me why non-exhaustive would be the default, requiring adding `@exhaustive` otherwise. Has anyone discussed doing it the other way around, this is, defaulting to exhaustive (no changes with prior Swift versions) and adding a `@nonExhaustive` tag instead as needed?

Apologies if this has been covered already.

Regards and thank you everyone for making Swift better!
Eneko


> On Dec 27, 2017, at 10:26 PM, Riley Testut via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <mailto: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 <mailto: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 <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 <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/0625d777/attachment.html>