[swift-evolution] [Proposal] Enums with stored properties

[Kevin Nattinger]

> On Oct 10, 2016, at 11:30 AM, Robert Widmann <devteam.codafi at gmail.com> wrote:
> 
> 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

I’m not sure where you got “bitfields” from, perhaps I was unclear. I think enums should be a set of cases, each case having its distinct and constant set of data with the same structure. If one entity needs data of different, dynamic structure and value at runtime, that is essentially the definition of a union.

> - 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 <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> This is the way Java enumerations work. 
>>> 
>>> https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html <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 <mailto: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/8288376f/attachment.html>