In general, I agree with everything in the proposal.
I’d like to propose these alternative extensions for clients:
1) As a client of an enum, I’d like to know in the future when a new value has
been added to an enum, since I may have to do something about it. How about
adding the “exhaustive” keyword to be used in the switch statement? Like
exhaustive switch excuse {
case eatenByPet:
// …
case thoughtItWasDueNextWeek:
// …
default:
// …
}
If exhaustive is used, there would be a warning if all cases aren’t covered
*even though default exists*. This means that I as the client thought I had
everything covered when I wrote this code.
As already mentioned, this makes the default case un-testable, which brings me
to
2) All non-exhaustive enums should have the pseudo value “default” that can be
used just like a regular value. This would allow you to write code like:
teacher.failedToHandInHomework(excuse: .default)
which would allow you to trip the default case in any code you may write.
-Kenny
> On Sep 13, 2017, at 12:17 PM, Jordan Rose via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Proposal updated, same URL:
> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md
>
> <https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md>.
>
> Thanks again for all the feedback so far, everyone!
> Jordan
>
>
>> On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> Sorry, I got distracted by other tasks! Both the discussion here and within
>> Apple has moved towards making "non-exhaustive" the default, which, to be
>> honest, I too think is the best design. I'll update the proposal today to
>> reflect that, though I still want to keep both the "nonexhaustive" and
>> "exhaustive" keywords for Swift 4 compatibility for now (or whatever we end
>> up naming them). The compatibility design is a little less ambitious than
>> Brent's; as currently proposed, Swift 4 mode continues to default to
>> 'exhaustive' all the time, even in the actual Swift 5 release.
>>
>> I still want to respond to Brent's points directly, but I think you and
>> Vladimir have done a good job discussing them already. I'll send out the
>> updated proposal tomorrow, after I have a little more time to think about
>> #invalid.
>>
>> Thanks for putting time into this!
>> Jordan
>>
>>
>>> On Sep 9, 2017, at 17:34, Rod Brown <rodney.bro...@icloud.com
>>> <mailto:rodney.bro...@icloud.com>> wrote:
>>>
>>> Jordan,
>>>
>>> Do you have any other thoughts about the ongoing discussion here,
>>> especially regarding Chris’ comments? As you’re the one pushing this
>>> forward, I’d really like to know what your thoughts are regarding this?
>>>
>>> - Rod
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
