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

[Matthew Johnson]

Sent from my iPad

> On Feb 11, 2017, at 5:11 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Closed would not be an access level, just an attribute orthogonal to the others.
> As Xiaodi pointed out, there's still no agreement on that — so basically I'm saying that I prefer your interpretation, because imho five access levels are already a alarmingly high number.

Well we're going to have a concept of closed enum regardless of how we spell it syntactically.  I don't think making it an access level adds any complexity over using an attribute.  I think it reduces complexity by making the language more consistent.

> 
>> What do you mean by the six different flavors?
> 1) cases with associated objects
> 2) raw-based enums
> 3) everything else (not that much different from int-based)
> 
> With the new attribute, there would be a new variant for each type, therefor six flavours (I choose this term because it's only small variation — but still, it might look quite complex to someone coming from C or Java).
> 
> The major issue I have with this change is how it will work in real live:
> When I write a library and declare that I'll never add new cases to an enum, who will enforce this?
> Will the compiler interact with git and look for release tags, or will there be a lockdown-command that records all cases and compares them with the last time the command was triggered?
> This feels really brittle to me, and I haven't seen a approach that would be fundamental different (and better).

We are not talking about *adding* closed enums to the language.  They already exist and will continue to exist.  We're just talking about how to spell them in the future when we also have resilient enums (i.e. allowing a library to add new cases in a future version without breaking compatibility).  I don't have a complete answer here about the details, but there is a plan to provide tool support to help with library evolution and detecting breaking changes.  

> _______________________________________________
> 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/20170211/499c61f2/attachment.html>