Sent from my iPad
> On Feb 10, 2017, at 9:22 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > >> On Fri, Feb 10, 2017 at 7:23 PM, Slava Pestov via swift-evolution >> <[email protected]> wrote: >> >>> On Feb 10, 2017, at 8:55 AM, Tino Heth <[email protected]> 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. This is correct. It isn't immediately obvious, but when you step back and consider things from a high level point of view it seems to fall pretty naturally out of the logic we used when we made `open` and access level. Closed is talking about the same thing `open` is: who is allowed to add to the set of cases, subclasses or protocols of an enum, class, or protocol. It just moves in the opposite direction from `public` than `open` does. Once you realize this, any other spelling of `closed` would make the language feel inconsistent IMO. If `open` works as an access level `closed` should also. > >>>> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
