> On Feb 10, 2017, at 10:55 AM, Tino Heth via swift-evolution 
> <swift-evolution@swift.org> 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.
> 
>> 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?

What do you suggest this implicit default case do?  Just break?  That seems 
like the only option besides trapping.  I wouldn’t want the compiler doing 
either of these after the fact.  If we’re going to allow a library to add new 
cases without making that a breaking change it must communicate that to users 
*ahead of time* and the compiler must require a default clause in any switch 
over that type.

> _______________________________________________
> 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

Reply via email to