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

[Xiaodi Wu]

On Wed, Oct 12, 2016 at 4:21 PM, Karl <razielim at gmail.com> wrote:

> > My point is that, IMO, this is all I want. Thus what I’m implying is
> that there’s probably not any ABI impact to (IMO) “fix” enums with
> associated values, and so I don’t know why this discussion keeps going on
> and veering into (what seems to me to be) overly complex territory when
> many of us just want a nicer way to express cases likes these - not a whole
> new enum model that has to break everything.
>
> To be fair, the title is "Enums with stored properties” and the OP insists
> it is not just syntactic sugar.
>
> I think we all want better syntax for working with enums. They are groups
> of related values, so surely they have many common properties, but the
> barrier between enum cases in the language is sometimes far stronger than
> the barrier between them semantically.
>
> Maybe some kind of actual stored properties would be nice. Not like the
> “RectSize” example in this thread, where the values were all constants, but
> like the “FileError” example, where every case has a URL associated value.
> For example:
>
> enum Something {
>     var timeTaken : TimeInterval
>
>     case oneThing(Int)
>     case anotherThing(Double)
>     case yetAnother(Bool)
> }
>
> is equivalent to:
>
> enum Something {
>     case oneThing(Int, TimeInterval)
>     case anotherThing(Double, TimeInterval)
>     case yetAnother(Bool, TimeInterval)
> }
>
> Since we know all payloads contain a TimeInterval and you didn’t specify a
> layout, we could lay them out in a predictable position for faster access.
> The compiler could probably do that anyway, even if you did specify an
> explicit tuple, but doesn’t today AFAIK. Maybe I’ll look at implementing
> that - we could maybe get away with it now, but it wouldn’t be worth the
> hassle once we have a stable ABI.


Yes, yes, let's talk about this in particular! I assume this offers
performance advantages over what's possible currently. Among the things I'd
like to find out: Was there a rationale for omitting this originally? Are
there any drawbacks in terms of performance of the simplest kinds of enums?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161012/24d09254/attachment.html>