[swift-evolution] Enums and Source Compatibility
Jordan Rose
jordan_rose at apple.com
Tue Sep 12 19:38:24 CDT 2017
I don't think RawRepresentable really has anything to do with this. Enums with payloads often don't have any particular reasonable raw values.
We could certainly spell non-exhaustive enums as "enum struct", but I don't think that'll be more obvious to other people than any of the names that have already been proposed.
Jordan
> On Sep 6, 2017, at 11:05, Jose Cheyo Jimenez <cheyo at masters3d.com> wrote:
>
> 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 at swift.org <mailto:swift-evolution at 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.brown6 at icloud.com <mailto:rodney.brown6 at 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_rose at apple.com <mailto:jordan_rose at 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 <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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170912/9b1b1191/attachment.html>
More information about the swift-evolution
mailing list