<div dir="ltr">Another thought:<div><br></div><div>The ternary operator uses the characters "?" and ":" very differently from the rest of the language where they relate to optionals (?) and type declarations/method parameters (:).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 3:11 PM, Marc Knaup <span dir="ltr"><<a href="mailto:marc@knaup.koeln" target="_blank">marc@knaup.koeln</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I also have no preference yet so I'll just throw in some thoughts.</div><div><br></div><div>** Existing Code **</div>The removal of the ternary operator would likely affect a lot of existing code.<div>A quick search for " ? " (with spaces) over a large app of our team yields 304 results.</div><div><br></div><div>Two simpler examples:</div><div><br></div><div><div><font face="monospace, monospace">[</font></div><div><font face="monospace, monospace"><span style="white-space:pre-wrap"> </span>"With Conditions": hasReport ? "yes" : "no",</font></div><div><span style="font-family:monospace,monospace;white-space:pre-wrap"> </span><font face="monospace, monospace">"With Image": hasImage ? "yes" : "no",</font></div><div><span style="font-family:monospace,monospace;white-space:pre-wrap"> </span><font face="monospace, monospace">"With Message": hasMessage ? "yes" : "no",</font></div><div><span style="font-family:monospace,monospace;white-space:pre-wrap"> </span><font face="monospace, monospace">"Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",</font></div><div><span style="font-family:monospace,monospace;white-space:pre-wrap"> </span><font face="monospace, monospace">"Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",</font></div><div><span style="font-family:monospace,monospace;white-space:pre-wrap"> </span><font face="monospace, monospace">"Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"</font></div><div><font face="monospace, monospace">]</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">view1.alpha = editing ? 1 : 0</font></div><div><font face="monospace, monospace">view2.alpha = editing ? 1 : 0</font></div><div><font face="monospace, monospace">view3.alpha = editing ? 0 : 1</font></div><div><font face="monospace, monospace">view4.alpha = editing ? 1 : 0</font></div></div><div><font face="monospace, monospace"><br></font></div><div>I am not sure using <font face="monospace, monospace">if…then…else</font> would make this better to read & understand or worse.</div><div><br></div><div><br></div><div>** Keyword <font face="monospace, monospace">then</font> **</div><div>Making then a keyword would also cost us another word so that change needs to be carefully considered.</div><div>In our large app I found just a single instance where <font face="monospace, monospace">then</font> was used for a variable's name:</div><div><span><br></span></div><div><font face="monospace, monospace"><span>func</span><span> reloadConfigurationAndThen(then: </span><span>() -> Void</span><span>) { … }</span></font><br></div><div><p>Promises use the word <font face="monospace, monospace">then</font> rather extensively: <a href="https://promisesaplus.com" target="_blank">https://promisesaplus.com</a></p></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson 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 dir="auto"><div>I'm not quite sure how I feel about this specific proposal yet but in general I do want to see conditional expressions and removal of the ternary operator.</div><div><br></div><div>I would like to see "else if" included in whatever we adopt as the final solution. Is there a reason this is omitted from this proposal? I apologize if that was discussed in the thread. I haven't followed every post. </div><div><br>Sent from my iPad</div><div><div><div><br>On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div>Hello All, </div><div><br></div><div>Been sick in bed all day, but decided to try to be productive…</div><div><br></div>I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,<div><br></div><div><a href="https://github.com/possen/swift-evolution/blob/master/0020.md" target="_blank">https://github.com/possen/swift-evolution/blob/master/0020.md</a></div><div><br></div><div>Thanks,</div><div>- Paul</div><div><br><div><br></div><div><br><div><blockquote type="cite"><div>On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <<a href="mailto:possen@gmail.com" target="_blank">possen@gmail.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">Implied in using the “then", if…then…else would aways require “else" when using “then” similar to how “guard" requires “else”. This will help to make the difference between statements and expressions clear.<div><br></div><div>let x = If cond then X else Y</div><div><br></div><div>is the full form, where “else" can not be omitted. </div><div><br></div><div><blockquote type="cite"><div>On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <<a href="mailto:possen@gmail.com" target="_blank">possen@gmail.com</a>> wrote:</div><br><div><div style="word-wrap:break-word"><div><br></div><br><div><blockquote type="cite"><div>On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><div>1. I would really hate to explain to someone when <b>if</b> needs a <b>then</b> and when it doesn't. That's the sort of inconsistency that shouldn't be added lightly.</div></div></div></blockquote><div><br></div><div>agreed definitely want to be careful with that. I think with braces meaning statements that differentiation can be made clear. I would certainly start with statements when describing, just as you usually don’t talk about the ternary operator until later. </div></div><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div>3. If we can somehow solve all of this, I think I'll be +1 for replacing (A ? B : C) with some sort of (<b>if</b> A <b>then</b> B <b>else</b> C).</div></div></div></blockquote><div><br></div>Yes that would be great.</div><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div>4. Generally, I wonder how hard would it be for all statements to be usable as expressions? Why didn't Swift go that way from the start?</div></div></div></blockquote><div><br></div><div>The biggest problem statement is you don’t need to exhaustively specify every outcome:</div><div><br></div><div>if cond {</div><div><span style="white-space:pre-wrap"> </span>print(“hello”)</div><div>}</div><div><br></div><div>whereas in an expression you have to specify what happens in the else.</div><div><br></div><div>let say = if cond then “hello” else “goodbye"</div></div><div><br></div><div>unless you go seriously off the deep end:</div><div><br></div><div>let say = if cond then “hello” </div><div><br></div><div> “say" then becomes an optional, *shudder*</div><div><br></div><div><br></div></div></div></blockquote></div><br></div></div></blockquote></div><br></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAdaxSAa57vVHzgOaGS3OJDr3kBSrQQ4LUow9XMreNnGSkOltVnJB1w7eSPQnCmAvsg-2FfCzxFcek37a-2BVd36PwEHGh5EqvhIo948Lr1lsgWaCdBXwEZxt6-2BFwdHf7roCv-2F1jb2h2r9BYeyHnOlSA-2BxOALuCbwUKtpnI70jPXFQaFh8-2Bwfx46L-2FVM8zbpCeQa-2FtE-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></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></span></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=6ZGE61OxINd5lLe2xYh9Ku-2BXbixWNr2nvfzp2IB1sZgyGF-2BKGEpH8nn4D8Nw9i1XMnAD61AsGp8lQXFbag-2B6f7gZMz4Y125guAxWdpK4sebTv2UR83D2z3MoDfJqPgYYLT8PQro5mflcoUeHIfCy9gmPG7uWpAeZrG9bFFYa-2BoA4Ym7T0eS7LN3So9yrU8aM-2BTGW4cClyytnOzkfreJ-2BFmO62uZeJ2asIjEBfH6rhFg-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" 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></blockquote></div><br></div>
</div></div></blockquote></div><br></div>