Here is an alternative view. I've been thinking about this and I feel that instead of adding this to an enum why not make RawRepresentable structs a swift construct.
You could declare it like this: enum struct { case a, b, c } This would be a struct that acts like an enum but it is open like a RawRepresentable but using the enum case sugar. > On Sep 5, 2017, at 5:37 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > It's in the "Alternatives Considered" section. :-) That was my desired design > when we started, but feedback convinced me that the break from Swift 4 mode > would be too drastic. The same valid code would have a different meaning > whether you were writing Swift 4 or Swift 5. > > Jordan > > >> On Sep 5, 2017, at 17:30, Rod Brown <rodney.bro...@icloud.com> wrote: >> >> Hi Jordan, >> >> I’m not sure how much bearing on this my comment will have. >> >> Have you considered having only “exhaustive” as a keyword, and make the >> default non-exhaustive? It seems that “exhaustive" would be the rarer case, >> as it promises a lot more about compatibility (much like there is no such >> thing as “non-final”). Also, non exhaustive seems a massive mouthful despite >> it probably being the correct term. >> >> - Rod >> >>> On 6 Sep 2017, at 10:19 am, Jordan Rose <jordan_r...@apple.com> wrote: >>> >>> I've taken everyone's feedback into consideration and written this up as a >>> proposal: >>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md. >>> The next step is working on an implementation, but if people have further >>> pre-review comments I'd be happy to hear them. >>> >>> Jordan > > _______________________________________________ > 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