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 <[email protected]> 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 
> <[email protected] <mailto:[email protected]>> 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 <[email protected] 
>>> <mailto:[email protected]>> 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 <[email protected] 
>>>> <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to