[swift-evolution] Proposal: Stored properties for enums

[Ilias Karim]

Great suggestion, Jonathan. I’ve encountered the desire for this feature a few times while implementing state machines for my iOS app.

How would switch statements pattern match enum stored properties?

Ilias

> On Dec 9, 2015, at 3:34 PM, Tommy van der Vorst via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> (Tommy, did you see the line in the original proposal suggesting that you'd initialize stored properties as if they were additional named associated values? E.g.: let expr = .Number(3, location: 5, length: 1). I think if you were to reassign expr -- if it were a var -- you'd need to re-assign location and length, too; they wouldn't transfer.)
> 
> Nope, I missed that (sorry). If at all, this seems a reasonable way to implement it. 
> 
> By the way it requires there be no duplicate field labels. Also it seems logical to either have a fixed initializer parameter order (first the associated values, then the labeled common ones in order of declaration), *or* to allow any order (in case all associated values have labels as well).
> 
> My only objection to this proposal is still whether the number of cases where this is useful warrants the added complexity and potential confusion for newcomers. I haven't encountered many situations where these stored common properties would be very useful but ymmv.
> 
> /T
> 
>> Op 10 dec. 2015, om 00:06 heeft Alex Lew <alexl.mail+swift at gmail.com <mailto:alexl.mail+swift at gmail.com>> het volgende geschreven:
>> 
>> Interesting proposal! In Swift's docs on Pattern Matching (https://github.com/apple/swift/blob/master/docs/Pattern%20Matching.rst <https://github.com/apple/swift/blob/master/docs/Pattern%20Matching.rst>), the inability to easily access a value that is relevant to all cases of an enum is explicitly mentioned as a minus of Swift's approach:
>> minus: needs boilerplate to project out a common member across multiple/all alternatives
>> The docs even mention that it might be worth providing "special dispensations for ... projecting out common members."
>> 
>> This seems like an elegant solution to the all-alternatives problem (though not the multiple-alternatives problem). +1
>> 
>> It is worth considering Frederick's point above that this essentially makes struct X { ... } the same as enum X { case OnlyCase; ... }. Also, you'd probably want to make sure that none of the associated values shared a name with a stored property, to avoid confusion when initializing (constructing?) new enums.
>> 
>> (Tommy, did you see the line in the original proposal suggesting that you'd initialize stored properties as if they were additional named associated values? E.g.: let expr = .Number(3, location: 5, length: 1). I think if you were to reassign expr -- if it were a var -- you'd need to re-assign location and length, too; they wouldn't transfer.)
>> 
>> -Alex
>> 
>> On Wed, Dec 9, 2015 at 4:44 PM, Tommy van der Vorst via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> > None of the state-like nature of enums would be lost.
>> >
>> > enum Something {
>> >  case StateA
>> >  case StateB(Double)
>> >  var prop: Int
>> > }
>> >
>> > Would simply be a another way to write:
>> >
>> > enum Something {
>> >  case StateA(Int)
>> >  case StateB(Double, Int)
>> > }
>> 
>> 
>> Sure, but do we really need special syntax then? To me the above way of writing is much clearer on which data is available at what point than the variant with the separate 'var' declaration. You can even label the different values in the associated data tuple.
>> 
>> Putting data shared across states in a separate 'var' declaration introduces some other issues as well: when an enum is reassigned (i.e. self = .StateB(...)), is the variable emptied somehow, or is it kept? How would you even initialize the value of a non-optional stored property that is not part of the case associated tuple (as the variables are not a 'requirement' of the case tuple, perhaps only optionals should be allowed)?
>> 
>> /T
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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 <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/c4e266fc/attachment.html>