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

[Jean-Daniel]

> Le 28 déc. 2017 à 21:17, Eneko Alonso via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 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?

IIUC, this is to help binary stability.
If a library developer write an enum without knowing about « @exhaustive », it can safely add another enum in a v2 of the library without breaking all the clients.


> 
> 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 <mailto: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 <mailto: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/6558d03d/attachment.html>