[swift-evolution] Warning when omitting default case for imported enums

Xiaodi Wu xiaodi.wu at gmail.com
Fri Feb 10 21:22:49 CST 2017


On Fri, Feb 10, 2017 at 7:23 PM, Slava Pestov via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Feb 10, 2017, at 8:55 AM, Tino Heth <2th at gmx.de> wrote:
>
> I'm not sure if I like the concept of having two kinds of enum.
>
>
> Why not? Bool-like enums would be declared ‘closed’, and would not require
> a default case (but adding a new case would then break ABI).
>
>
> Well, enums are already (relative) complex, and with this addition, there
> would be six different flavors.
> Imho it would be less bad if we could recycle existing modifiers, but with
> a hypothetic "closed" access level added as well, I have strong doubts that
> the feature carries its weight.
>
>
> Closed would not be an access level, just an attribute orthogonal to the
> others. What do you mean by the six different flavors?
>

My read of Matthew Johnson's pitch is that `closed` is to be a sixth access
level.

For better or worse we need the ability to define enums that admit new
> cases without breaking ABI. Whether or not this is the default for all
> enums, or enabled with a special attribute can be designed later when we
> send out evolution proposals for resilience-related features.
>
> Intuitively, I thought this should not affect ABI… but no matter what
> instability this is, I guess it could definitely crash an application that
> is confronted with an unexpected case ;-)
>
> Wouldn't it be possible to create an implicit default case for every
> switch-statement?
>
>
>
> _______________________________________________
> 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/20170210/6b1b0a41/attachment.html>


More information about the swift-evolution mailing list