<div dir="ltr"><span style="font-size:13px">> keeping expressions and statements as separate concepts</span><br><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">I </span><span style="font-size:13px">seriously </span><span style="font-size:13px">could not care less about that.</span></div><div><span style="font-size:13px"><br></span></div><div>Wait wait, I'm exaggerating! I wouldn't want Swift to become a language like Javascript where you forget to type a single character, and discover your program runs without complaint (assigning some bizarre boolean value as a result).</div><div><br></div><div>But if we're talking about the 'Switch' statement, as originally proposed, it takes a lot more characters, and luck, to get your app to compile and run. For me, I'd way rather have the convenience. As far as I'm concerned, unless I'm choosing a variable name, the more I have to type, the more likely I'm going to make a mistake.</div><div><br></div><div>This is why I think the ternary, for example, gets a bad rap (a bad rap *at the moment* anyway. I can't keep track, are "goto" and OOP bad this year?). The clarity you gain with a ternary is the fact that "this statement exists to assign a value to Foo." You break that into several lines, and that clarity can evaporate into the ether.</div><div><span style="font-size:13px"><br></span></div><div>So the reason I like your proposal, is that I want a way to preserve that clarity of "this line exists to assign a value to Foo" when I'm mapping something. The existing options, i.e.: the alternatives about I complained earlier in this thread, leave me with extra code whose purpose is solely to support that assignment to Foo. So, let's say I do it by extending an enum with an init that has a corresponding set of values... the purpose of that extension is no longer as clear (e.g.: "this init exists to support a line, somewhere else in this file, that assigns a value to Foo"). If I use a Switch statement, as it currently exists, it's a bunch of lines - and don't forget that "let Foo" needs to be declared *before* the Switch statement because of scope... it's so much more complicated than your proposal.</div><div><br></div><div>I don't know if I added anything helpful here other than complaining :) Needless to say, I still support your proposal </div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 19, 2015 at 9:57 PM, Paul Ossenbruggen 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Dec 19, 2015, at 8:37 PM, Dennis Lysenko via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">+1 to Jordan's points as well. <div><br></div><div>Generally speaking, there is clearly a wide variety of things that cause people to be interested in this particular proposal and I don't think we can reconcile all of them. For example, I think that "collapsing an if statement into one line" isn't a good enough reason to introduce the clutter and potential for abuse of the original ternary syntax into a codebase, so I generally float the idea to ban it from projects I'm involved in as soon as I see it pop up in one. At the same time, there seem to be people who are enamored with the concept, and maybe instead they talk in this thread because they want a way to condense a switch statement into one line. And still others think that there is no rush to think about getting rid of ternary, unless we come up with something equally concise or with significant advantages to warrant removing it (all valid points).<br><div><br></div><div>I'm not <i>against</i> Paul's idea, but if it matters at all (i.e. if you are worried other people will think like me), if this syntax is released, I will most likely float the idea of opting out of it immediately to my project collaborators. </div><div><br></div><div>While interesting for quick, proof of concept coding sessions, it already has some of the readability and abusability disadvantages already present in ternary, and it's still just in the proposal stage. </div><div><br></div><div>I only hope that this doesn't preclude progress on turning fully-qualified (and indented) statements into expressions.</div></div></div></div></blockquote><div><br></div></span>Good feedback!<br><div><br></div>Personally, I kind of hope that that is not the direction of Swift. I think there is quite a bit of value in keeping expressions and statements as separate concepts. If you need to do a bunch of things to get the result of an expression then use the statement construct or move it into a method. </div><div><br></div><div>Having statements that act as expressions encourages code that has side effects, which goes against one of the core concepts of functional programming. If I am working on a team, and someone wants to add some new feature and they see a big indented “if” with braces, they will just stick it in there and ignore that it is a functional approach. That new statement they add may add a bunch of side effects and add bugs to the code. If it is an expression that temptation will be less likely. They will see that this code is intended to work as an expression and won’t be able to just stick another statement with a bunch of side effects into it. </div><div><br></div><div>My proposal is about making expressions into first class citizens in terms of control flow. Its main purpose is definitely not about doing things on one line, that is just a side benefit if it works for your particular situation. This proposal supports and encourages multiline formatting and I think actually makes things cleaner and clearer than the statement forms. </div><div><br></div><div>But this feedback and Jordan’s is making me think that the Hybrid approach in Alternatives Considered may be more appealing to everyone. I was thinking conciseness might be preferable given some of the feedback I got from Chris and others, but after reading some other threads, clarity wins out over conciseness. This alternative may win for clarity. So I might go back and rethink that, but before I do that, I hope that more people could tell me if they like it better or do they like the ?( syntax better.</div><div><br></div><div>- Paul</div><div><br></div><div><br></div><div><blockquote type="cite"><div><div><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 19, 2015 at 10:57 PM Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> It's a nice, consistent proposal, but I don't feel like this solves any of the complaints about the existing ternary operator:<br>
><br>
> - It's not obvious what it does when you first learn it.<br>
> - The '?' doesn't have anything to do with Optionals.<br>
><br>
> It is a way to put 'switch' into an expression. I'm not a fan of the two different colons, but that's "just" syntax.<br>
<br>
+1 to all that<br>
<br>
> Jordan<br>
><br>
>> On Dec 18, 2015, at 14:04 , Paul Ossenbruggen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> All,<br>
>><br>
>> I think, I finally might have the answer to improving ternary, with such a bold statement come some pretty high expectations but I think, I might actually have done it this time :-)<br>
>><br>
>> I am calling it the Demux Expression, it builds on the benefits of ternary and switch while improving on those.<br>
>><br>
>> <a href="https://github.com/possen/swift-evolution/blob/master/proposals/0024.md" rel="noreferrer" target="_blank">https://github.com/possen/swift-evolution/blob/master/proposals/0024.md</a><br>
>><br>
>> This is a first draft, thanks in advance for feedback!<br>
>><br>
>> - Paul<br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org" target="_blank">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>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">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>
<br>
-Dave<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=emrIhnP1hIf76Foxxv4NNJQX-2FWhcznESwKBSwD1MEwwzzVRikMe383WAm-2BnOhnC5yVEqJSX7iElquM1RcRrIqPLgfOJ0rpVJ-2Bs29HCyrM-2F1fpH5oasLf5ou4C7YdEV04nIdFH5LRqZWlQRBv2Xj1GKLUwf0iIl8utpViYm706VP4qjWZTNnZBsaVBCU6wlfo8omOWG3vAmjaYnEll9bicpsv8HGYK-2BI-2FW-2FWzXvpdPug-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<span class=""><br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=l3fs1g-2F466j3y5fD5Q61KddsTTCmXL0uxw3XoAMFFNihG7DwRlKVebHq1v-2F2YSp52cMpaAGI8ThDkIwQNIIHnFmUpYpRPdABujgiQaCEORxY8Nm6Y4DCn46rnVlIK36kbWpmPO-2BGM9JoyEOcnVHPM3dYk00evjLu8NwOyKkp1iamHV4vXuKvLfxwRo-2F8nYoPGWUqi-2B2NkHCI-2FMkHR2Ww5WlPhlTJ1n2Ea3WftspmKqg-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<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>
<br></blockquote></div><br></div>