<div dir="ltr"><div class="gmail_extra">Interesting proposal! In Swift's docs on Pattern Matching (<a href="https://github.com/apple/swift/blob/master/docs/Pattern%20Matching.rst">https://github.com/apple/swift/blob/master/docs/Pattern%20Matching.rst</a>), the inability to easily access a value that is relevant to <i>all </i>cases of an enum is explicitly mentioned as a minus of Swift's approach:</div><ul style="padding:0px 0px 0px 2em;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px"><li style="">minus: needs boilerplate to project out a common member across multiple/all alternatives</li></ul><div class="gmail_extra">The docs even mention that it might be worth providing "special dispensations for ... projecting out common members."</div><div class="gmail_extra"><br></div><div class="gmail_extra">This seems like an elegant solution to the all-alternatives problem (though not the multiple-alternatives problem). +1</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">(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.: <span style="font-size:13px">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.)</span></div><div class="gmail_extra"><br></div><div class="gmail_extra">-Alex</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 4:44 PM, Tommy van der Vorst via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> None of the state-like nature of enums would be lost.<br>
><br>
> enum Something {<br>
> case StateA<br>
> case StateB(Double)<br>
> var prop: Int<br>
> }<br>
><br>
> Would simply be a another way to write:<br>
><br>
> enum Something {<br>
> case StateA(Int)<br>
> case StateB(Double, Int)<br>
> }<br>
<br>
<br>
</span>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.<br>
<br>
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)?<br>
<br>
/T<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>