[swift-evolution] [Proposal] Enums with stored properties
Robert Widmann
devteam.codafi at gmail.com
Mon Oct 10 13:30:08 CDT 2016
By imposing that kind of separation you leave an entire class of generic and structural programming patterns off the table. An enumeration is not just an enumeration of constants, it is an enumeration of data, and data takes far more useful forms than just bitfields - similarly when it does have that form it fits precisely into the form of an enum with no cases? Why artificially separate the two concepts when they’re clearly one and the same?
~Robert Widmann
> On Oct 10, 2016, at 2:24 PM, Kevin Nattinger via swift-evolution <swift-evolution at swift.org> wrote:
>
> I agree wholeheartedly. An enum case should be a compile-time constant. IMO, “enums” with associated values should properly be a separate entity, called “union” as that’s essentially what they are.
>
>> On Oct 10, 2016, at 10:31 AM, Kenny Leung via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> This is the way Java enumerations work.
>>
>> https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
>>
>> I think it is a good model, and I think Swift enumerations should also work the same way.
>>
>> An enumeration is a finite set of things. It’s really inconvenient to have to limit those things to have only a single attribute.
>>
>> -Kenny
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/20161010/efd616ce/attachment.html>
More information about the swift-evolution
mailing list