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

[David Hart]

Perhaps it is a bit ugly, but I don’t know if allowing stored properties on enums is the solution: that looks very ugly to me too.

> On 10 Oct 2016, at 02:36, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I would love to be able to have stored properties in addition to the varying elements. 
> 
> Now, I end up creating a secondary struct T and doing case a(T, whatever), b(T, whatever), c(T, whatever), etc. where the same associated structure is every case, *or* I end up putting the enum into a struct which means the guiding semantics are the struct and not the enumeration. Both approaches are ugly. 
> 
> -- E
> 
>> On Oct 9, 2016, at 6:03 PM, Jay Abbott via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Mateusz,
>> 
>> To me, "Enumeration defines a type with well defined set of possible values" seems to contradict the idea of having properties that can have different values. What could you do with this special enum - what would the code that uses it look like?
>> 
>> 
>> 
>> On Sun, 9 Oct 2016 at 04:56 Robert Widmann via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I’ve started doing this to try and mimic “Smart Constructors” in Haskell and I think it works quite well.
>> 
>> struct Format {
>>   enum FormatBacking {
>>     case SMALL(Int, Int)
>>     case MEDIUM(Int, Int)
>>     case LARGE(Int, Int)
>>   }
> 
> _______________________________________________
> 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/51eac2fc/attachment.html>