[swift-evolution] Proposal: Stored properties for enums
Jonathan Hise Kaldma
info at hisekaldma.com
Thu Dec 10 04:15:03 CST 2015
>> (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.
Yup, reassigning an enum is really creating a new enum, so the properties wouldn't transfer.
> 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).
Associated values today have to be initialized in the order they're defined (whether they have names or not), and I don't think that needs changing.
I think the associated values should still come first, since they're more closely related to the case and they're the values you're more likely to be interested in. The properties are the "extra stuff".
> 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.
This might be one of those tools that looks really strange if you don't need it, but if you do need it, it's the exact right tool for the job.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution