<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>I think that we need to get past the “leftovers from C” being a bad thing mindset. Familiar constructs make Swift easier for programmers (its target audience) easier to learn.</div>
<div><br>
</div>
<div>Point by point:</div>
<div><br>
</div>
<ol>
<li>Being a holdover from C isn’t a bad thing. We can take things that were useful in C and make them part of Swift. Who said C language elements were a non-goal of Swift. And to the “ternary operator is hard to learn” point. This point gets made over and over
in proposals to change Swift, ease of learning is like performance and security – you can never have enough so there is no counter-argument. If you can’t learn the ternary operator, Swift isn’t the language for you, because what are you going to do when you
get to generics and higher order functions.</li><li>If the ternary operator adds complexity to the compiler then it really isn’t a holdover from C. We have quite a long time to know how to parse it from our C legacy.</li><li>See #1, new users are always confused about everything. They don’t stay that way. The language doesn’t need to be tuned to support it’s non-users. Most developers understand the ternary operator, and it is useful to them. Who is this language for?</li><li>The “:” appears in other places in the grammar. So what. So do parenthesis and brackets. It is just a token used in a grammar rule as a separator, it doesn’t have a meaning on its own, and it shouldn’t have one that isn’t its function.</li><li>So your argument is to make the ternary expression longer to discourage nesting. This is much different than the argument for function(a++, ++a) where order of function parameter evaluation influenced the code, but was not expressed by it. Everything is
fully expressed by the ternary operator including order of evaluation.</li><li>I see no problem with it being limited to bool. I don’t want Javascript’s “” == false.</li><li>What would be proposed (and has been) is the if expression which is more verbose but easier to read</li><li>Again, the C hate.</li><li>You leave out the reason for those languages to leave out the ternary operator. What was their rationale?</li><li>I’m sorry you had a hard time with it. But you learned it, and now you can apply that knowledge to any language that has it. To add to the anecdotal evidence you provided, I did not have a hard time learning it.</li></ol>
<div>I can distill this down to “C is old and not modern so lets get rid of anything from C” and “I had a hard time learning the ternary operator"</div>
<div><br>
</div>
<div>Bottom line, most developers know the ternary expression if they come from C, C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different for style reasons. We will be making a niche language, because what you learn isn’t portable to another
language like it is if you learn Java, then get a job programming in C#.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span><<a href="mailto:swift-evolution-bounces@swift.org">swift-evolution-bounces@swift.org</a>> on behalf of Mark Sands via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
<span style="font-weight:bold">Reply-To: </span>Mark Sands <<a href="mailto:marksands07@gmail.com">marksands07@gmail.com</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, October 26, 2016 at 09:55<br>
<span style="font-weight:bold">To: </span>William Sumner <<a href="mailto:prestonsumner@me.com">prestonsumner@me.com</a>><br>
<span style="font-weight:bold">Cc: </span>Swift-Evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
<span style="font-weight:bold">Subject: </span>[External] Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<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">
<div style="word-wrap:break-word">
<div>Training users to expect source-breaking churn would be highly damaging to the language. The removal of C-style for loops and increment/decrement operators came with sufficient justification beyond their being inherited from C. I don’t think there’s a
sufficient justification for this change, especially with the bar set high for such changes. </div>
<div><br>
</div>
<div>Preston</div>
</div>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">My apologies for skewing the conversation off-topic. I think what I meant to imply is that we shouldn't be afraid of a deprecation warning. Migrating away from a ternary operator is trivial, and the consequences usually come with better
readability.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Ignoring my statement about "leftovers from C" opposition, I
<i>do</i> think there is sufficient and very strong justification from the 10 items that Charlotte has listed. I think it would be more valuable if one could pick apart each bullet point they find excusable and list their reasons why it's not compelling enough
to warrant change.</div>
<div class="gmail_extra">
<div class="" style="font-family: -webkit-standard;">+ V2 Checkin API</div>
<div class="" style="font-family: -webkit-standard;">+ V2 Checkout API</div>
<div class="" style="font-family: -webkit-standard;">+ V2 Get Admission Records [Updated]</div>
<div class="" style="font-family: -webkit-standard;">+ V2 Get Scan Records</div>
<div class="" style="font-family: -webkit-standard;">- New SQLite Data File generation</div>
<div class="" style="font-family: -webkit-standard;">- V2 Get User Events</div>
<div class="" style="font-family: -webkit-standard;">- V2 Scan Record Submission</div>
<div class="" style="font-family: -webkit-standard;"><br class="">
</div>
<div class="" style="font-family: -webkit-standard;">- GDO Ticket Purchase Integration API</div>
<div class="" style="font-family: -webkit-standard;"><br class="">
</div>
<div class="" style="font-family: -webkit-standard;">- V2 Get Ticket Record(s) [New]</div>
<div class="" style="font-family: -webkit-standard;">- V2 Ticket Creation API [Updated]</div>
<div class="" style="font-family: -webkit-standard;">- V2 Ticket Info API [New]</div>
<div class="" style="font-family: -webkit-standard;">- V2 Ticket Transfer API [New]</div>
<div class="" style="font-family: -webkit-standard;">- V2 Ticket Re-issue API [New]</div>
</div>
</div>
</div>
</div>
</span>
</body>
</html>