<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="">Since I wanted to start playing with this feature now to see how I would use it. I went ahead and built the beginning of a library <a href="https://github.com/joalbright/Switchary" class="">https://github.com/joalbright/Switchary</a> (feel free to add to it, I plan on continuing to support and advance it until Swift gives me reason not to)<div class=""><br class=""></div><div class="">:) Yes it is called Switchary… just trying to have some fun. I know it is more verbose than what would be available if it were apart of the stdlib, but I am impatient.</div><div class=""><br class=""></div><div class=""><div class="">
<br class="Apple-interchange-newline"><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=""><font color="#8d8d8d" class=""><span class="Apple-converted-space">&nbsp;</span>Nerd . Designer . Developer</font></span><font color="#464646" class=""><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="">Jo Albright</span></font><br style="color: rgb(0, 0, 0); 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=""><br style="color: rgb(0, 0, 0); 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="">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 2:23 AM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Jan 6, 2016, at 8:35 PM, Paul Ossenbruggen via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class="">Hi Charles,<br class=""><br class="">Chris, already said he did not like ? being used for ternary because it was already used for optionals. I think because of historical precedent it may be acceptable here. &nbsp;I have tried combos earlier with ! and got no support, admittedly not with the same usage as yours. <br class=""></blockquote><br class="">Hi Paul (and others),<br class=""><br class="">Here’s an updated opinion from me - keep in mind that this isn’t gospel, just my opinion, and subject to change :-) &nbsp;<br class=""><br class="">Basically I’ve settled on the idea that there is nothing better-enough that would be worth changing the ternary ?: for. &nbsp;Anything we came up with would be “weird” and diverge from any existing practice out there, and therefore be impossible to justify. &nbsp;That’s why I updated the commonly_proposed.md list.<br class=""><br class="">That said, I think that the terseness that ?: provides is important. &nbsp;If you can agree to both points, it sounds like that means that ?: is here to stay, with its existing spelling. &nbsp;This also means that the dream of divorcing ?: from optional syntax has failed.<br class=""><br class=""><br class="">That leaves us with the question of what to do with switch-as-expression. &nbsp;I’m still pretty unmotivated by any of the ML/haskell like syntaxes that lead to giant hanging statements-like things indented to the right. &nbsp;Instead, the idea of embracing the weirdness that is ?: and extending it to pattern matching feels like the best path. &nbsp;Something akin to:<br class=""><br class="">let x = someValue ? <br class=""> &nbsp;&nbsp;case &lt;pattern1&gt;: result1<br class=""> &nbsp;&nbsp;case &lt;pattern2&gt;: result2<br class=""> &nbsp;&nbsp;case &lt;pattern3&gt;: result3<br class=""> &nbsp;&nbsp;default: result4<br class=""><br class="">would make sense: it is totally unambiguous (‘?' followed by ‘case’ drives this, and goes until a default case). The presence of the (strongly syntax highlighted) case statements means that people can flow this onto a single line if they want, and I also like it that provides a way to get the power of “if case/else” inline in an expression as well for the simplest pattern matching cases (e.g. checking for one enum value, or matching a string value against a regex someday).<br class=""><br class="">If we went with this, I think it would make sense to keep colons, and use refutable patterns (as seen in switch statements) as the pattern grammar. &nbsp;I’d lean towards not allowing where clauses on the patterns, and the results would obviously have to be single expressions (without a return or other statement) just like ?:. &nbsp;Perhaps that syntax should require or allow commas between the cases, I don’t have a strong opinion about that.<br class=""><br class=""><br class="">So in terms of the ideas you are kicking around, this one seems promising to me. &nbsp;That said, there is still a huge and hard question to answer here: would this feature pay for itself? &nbsp;It is clear that any feature of this ilk will be making the language more complex. &nbsp;Would code that uses it actually be *better* (e.g. more *clear*) than code that isn’t using it today? &nbsp;What ways can be measured to justify adding this to Swift?<br class=""><br class="">-Chris<br class=""><br class=""><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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>