> 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