<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Great suggestion, Jonathan. I’ve encountered the desire for this feature a few times while implementing state machines for my iOS app.<div class=""><br class=""></div><div class="">How would switch statements pattern match enum stored properties?</div><div class=""><br class=""></div><div class="">Ilias<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 9, 2015, at 3:34 PM, Tommy van der Vorst via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><div dir="ltr" class=""><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 class="" 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></blockquote><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Nope, I missed that (sorry). If at all, this seems a reasonable way to implement it. </div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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),<span class="Apple-converted-space"> </span><i class="">*or*<span class="Apple-converted-space"> </span></i>to allow any order (in case all associated values have labels as well).</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">/T</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">Op 10 dec. 2015, om 00:06 heeft Alex Lew <<a href="mailto:alexl.mail+swift@gmail.com" class="">alexl.mail+swift@gmail.com</a>> het volgende geschreven:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><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" class="">https://github.com/apple/swift/blob/master/docs/Pattern%20Matching.rst</a>), the inability to easily access a value that is relevant to<span class="Apple-converted-space"> </span><i class="">all<span class="Apple-converted-space"> </span></i>cases of an enum is explicitly mentioned as a minus of Swift's approach:</div><ul class="" 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 class="">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 class=""></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 class=""></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 class=""></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 class="" 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 class=""></div><div class="gmail_extra">-Alex</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Dec 9, 2015 at 4:44 PM, Tommy van der Vorst via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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 class="">><br class="">> enum Something {<br class="">> case StateA<br class="">> case StateB(Double)<br class="">> var prop: Int<br class="">> }<br class="">><br class="">> Would simply be a another way to write:<br class="">><br class="">> enum Something {<br class="">> case StateA(Int)<br class="">> case StateB(Double, Int)<br class="">> }<br class=""><br class=""><br class=""></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 class=""><br class="">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 class=""><br class="">/T<br class=""><div class=""><div class="h5"><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=Ao79r2458aNQsMsE0Edafow-2FpTRtMK12Z5ahkO3eRdC1hAbAdbUhXc5YWSoJrhNECBVdL0Kh29ARUw17kWa7D1lxQxpYLFO-2B4E8iyNo00hI2xUvlDtHRkzsRPlwDLlpprD-2B9ejzCLBUHBLAb6UZNCeDoCb1x3PqyhUqwpaY9kASKSsoR-2Bp4aw36LGPSppsI-2FGDbwGpufyvUWoCy-2BX9sG3ODhJbqTgKtij6ZoRASB65A-3D" alt="" width="1" height="1" border="0" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span></span><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></div></body></html>