As Chris mentioned, such a proposal is entirely out of scope for this phase of Swift 4, it's a commonly rejected proposal that required a high bar for reconsideration even during the Swift 3 evolution process, and that bar is even higher going forward because source breaking changes will be extremely frowned upon. Because it's such a high-traffic list, this is really not an ideal thread to resurrect...<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 28, 2016 at 5:56 PM Soroush Khanlou via swift-evolution <<a href="mailto:swift-evolution@swift.org">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"><div style="word-wrap:break-word" class="gmail_msg">+1 from me as well.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I was initially unconvinced, until Charlotte showed me her proposal. She lays out the case very well, and I agreed to help edit the proposal.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It’s a confusing and bad operator, and it doesn’t give us anything that a function on Bool can’t give us. The way I see it, this isn’t very different from C-style for loops, the ++ operator, or explicit optionality, which are all features where Swift departs from traditional C orthodoxy.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It’s easy to abuse and hard to reason about. Special cases like this operator have to really earn their place in the language. This one doesn’t carry its weight.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Soroush</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 26, 2016, at 11:42 AM, Joshua Alvarado via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-9185505750568932943Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg"></span></div><div class="gmail_msg"><div class="gmail_msg">-1</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I love the idea of challenging the syntax but without any real benefit I can see it harder for new devs and it will cause breaking changes that doesn't outweigh the cause. The syntax z ? x : y is not hard to comprehend and expresses powerful statements in just a simple line. I do agree it is abused. It is used in places that a fuller if statement would help make sense of the code. It is on the developer to help make the operator easier to understand. The operator is the same across many languages which helps create a standard. <br class="gmail_msg"><br class="gmail_msg">Alvarado, Joshua</div><div class="gmail_msg"><br class="gmail_msg">On Oct 26, 2016, at 9:12 AM, Mark Sands via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">Strong <b class="gmail_msg">+1</b> from me.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This simply feels like the right approach for Swift, as we see the language head in a direction that has abandoned traditional C-style idioms. As swift has already dropped support for the ++/-- operators and C-style for loops it makes logical sense that dropping the ternary operator (or replacing with a more Swift-like idiom) should follow.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As a side note, after upgrading my swift code to Swift 3, I feel as though I've become un-phased at future source breaking changes until full stability is met and set in stone. If they're worth it, bring them on, I say.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Mark</div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Wed, Oct 26, 2016 at 8:52 AM, Mike Kasianowicz via swift-evolution <span dir="ltr" class="gmail_msg"><<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" 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 dir="ltr" class="gmail_msg">I like the idea in theory, but I also like the existing ternary operator. Could some of this be accomplished without drastic changes?<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Some alternative ideas-</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">1) Codify ternary operator declaration in the language, but make some common-sense restrictions to reduce expression parsing complexity (no line breaks, enforced parens, 'simple' arguments, stuff like that). If there were an extension like you propose in addition, my preference would be a verb like "select".</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">2) Make it a binary operator with autoclosure tuple on the RHS (is it possible to put autoclosure within a tuple?):</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div style="font-size:14.4px" class="gmail_msg">public static func ?<T>(_ value: Bool, _ branches: (_ t: @autoclosure () -> T, _ f: @autoclosure () -> T)) -> T {</div><div style="font-size:14.4px" class="gmail_msg"> if value {</div><div style="font-size:14.4px" class="gmail_msg"> return branches.t()</div><div style="font-size:14.4px" class="gmail_msg"> } else {</div><div style="font-size:14.4px" class="gmail_msg"> return branches.f()</div><div style="font-size:14.4px" class="gmail_msg"> }</div><div style="font-size:14.4px" class="gmail_msg"> }</div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="m_-9185505750568932943gmail-h5 gmail_msg">On Tue, Oct 25, 2016 at 11:51 PM, Charlotte Angela Tortorella via swift-evolution <span dir="ltr" class="gmail_msg"><<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br class="gmail_msg"></div></div><blockquote class="gmail_quote gmail_msg" 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 class="gmail_msg"><div class="m_-9185505750568932943gmail-h5 gmail_msg"><div style="word-wrap:break-word" class="gmail_msg">Preamble: I've read over the threads that already exist about the ternary operator and to be honest they're a complete mess without a single fully formed proposal.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Pitch: I'd like to simplify the syntax, compiler complexity and learning curve for newcomers when it comes to dealing with the ternary function. The best way to do that, in my opinion, is to remove it entirely and add a new function with better semantics that takes care of ternary operations entirely within the Swift language.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">gist: <a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c" class="gmail_msg" target="_blank">https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg">Replace the `?:` operator with an in-language function</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Proposal: TBD</div><div class="gmail_msg">Author: [Charlotte Tortorella](<a href="https://github.com/qata" class="gmail_msg" target="_blank">https://github.com/qata</a>)</div><div class="gmail_msg">Editor: [Soroush Khanlou](<a href="https://github.com/khanlou" class="gmail_msg" target="_blank">https://github.com/khanlou</a>)</div><div class="gmail_msg">Review Manager: TBD</div><div class="gmail_msg">Status: TBD</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#introduction" class="gmail_msg" target="_blank">Introduction</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The ternary operator in Swift was added early in development, as a holdover</div><div class="gmail_msg">from C. This document is an attempt to provide a clear look at the ternary</div><div class="gmail_msg">operator without the baggage of the languages that came before, and comes</div><div class="gmail_msg">to the conclusion that we should deprecate and remove the ternary operator</div><div class="gmail_msg">in favor of an extension to `Bool`.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As a quick refresher, here's what the ternary operator looks like:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">let a = 10</div><div class="gmail_msg">let b = 20</div><div class="gmail_msg">// If a is less than b, sets e to "foo", else sets e to "bar"</div><div class="gmail_msg">let e = a < b ? "foo" : "bar"</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#advantages-of-the-ternary-operator" class="gmail_msg" target="_blank">Advantages of The Ternary Operator</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The primary advantage of this operator is its terseness and expressive</div><div class="gmail_msg">capability. It's shorthand for (e.g.):</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">let a = 10</div><div class="gmail_msg">let b = 20</div><div class="gmail_msg">let e: String</div><div class="gmail_msg">if a < b {</div><div class="gmail_msg"> e = "foo"</div><div class="gmail_msg">} else {</div><div class="gmail_msg"> e = "bar"</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The second advantage of Swift supporting the ternary operator is continuity</div><div class="gmail_msg">with C, and other common languages in the extended C family (C++, Objective-C,</div><div class="gmail_msg">Java, C#, Javascript, etc). People coming to Swift from these other languages</div><div class="gmail_msg">may reasonably expect this operator to exist. That said, there are also</div><div class="gmail_msg">popular languages which have kept the majority of C operators but dropped the</div><div class="gmail_msg">ternary operator (e.g. [Go](<a href="https://golang.org/doc/faq#Does_Go_have_a_ternary_form" class="gmail_msg" target="_blank">https://golang.org/doc/faq#Does_Go_have_a_ternary_form</a>) and [Rust](<a href="https://github.com/rust-lang/rfcs/issues/1362" class="gmail_msg" target="_blank">https://github.com/rust-lang/rfcs/issues/1362</a>)).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#disadvantages-of-the-ternary-operator" class="gmail_msg" target="_blank">Disadvantages of The Ternary Operator</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">1. The existence of the ternary operator as a holdover from C is to increase</div><div class="gmail_msg">the familiarity of the Swift language for C family developers, at the expense</div><div class="gmail_msg">of newcomers. Established developers do much better with learning concepts</div><div class="gmail_msg">than newcomers to programming and probably don't need their hands held</div><div class="gmail_msg">with this carry over of an operator.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">2. The ternary operator adds complexity to the compiler, because it requires</div><div class="gmail_msg">special handling. It is the only operator that requires two components to</div><div class="gmail_msg">work (both the `?` and the `:`), it uses a character that is excluded from</div><div class="gmail_msg">being used in other operators (`:`), and it isn't defined in the standard</div><div class="gmail_msg">library.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">3. The ternary operator's usage of `?` can be confusing</div><div class="gmail_msg">to new users. Every other instance of `?` is associated with</div><div class="gmail_msg">`Optional` values.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">4. The ternary operator uses `:`, which is already a heavily overloaded</div><div class="gmail_msg">symbol in Swift. `:` is used in hash tables, type annotations for variables,</div><div class="gmail_msg">class inheritance, and protocol conformance.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">5. The ternary operator's short length lends it to being abused in the</div><div class="gmail_msg">nested ternary operator anti-pattern. This is similar to the `++` and</div><div class="gmail_msg">`--` operators, which were removed in Swift 3. While they worked fine and were</div><div class="gmail_msg">readable enough when used alone, using them multiple times in a single</div><div class="gmail_msg">expression like `function(a++, ++a)` made them highly unreadable and</div><div class="gmail_msg">confusing.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">6. This operator is only applicable to a single type, `Bool`.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">7. If the ternary operator weren't in common usage, it would not be proposed</div><div class="gmail_msg">for Swift. Higher clarity can be achieved with common language features by</div><div class="gmail_msg">creating an extension to `Bool`.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">8. The ternary operator was created for and is much more suited to a language</div><div class="gmail_msg">like C, where there were no generics and as such no alternative to an</div><div class="gmail_msg">unintuitive operator.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">9. Several other modern languages, like Rust and Go discussed earlier, have</div><div class="gmail_msg">eschewed the usage of the ternary operator entirely. Other languages that have</div><div class="gmail_msg">special constructs similar to `?:`, such as `if then else` in Haskell have</div><div class="gmail_msg">[discussed removing it](<a href="https://wiki.haskell.org/If-then-else#Is_If-Then-Else_so_important.3F" class="gmail_msg" target="_blank">https://wiki.haskell.org/If-then-else#Is_If-Then-Else_so_important.3F</a>). `if then else` is identical to the `?:` operator,</div><div class="gmail_msg">excepting that it's prefixed by `if`, while `?:` has no prefix.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> Example: `if True then 10 else 20`</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">10. On a more personal and anecdotal note, the ternary operator gave me more</div><div class="gmail_msg">trouble than any other operator when I was first learning how to program.</div><div class="gmail_msg">I’ve also spoken to several other people who expressed similar sentiments</div><div class="gmail_msg">about this operator’s inscrutability.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#proposed-approach" class="gmail_msg" target="_blank">Proposed Approach</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">We should drop the ternary operator in favor of a new extension to `Bool`.</div><div class="gmail_msg">There are a few possibilities for the naming of this function. We've provided</div><div class="gmail_msg">four for consideration in this proposal, but are open to other options as well.</div><div class="gmail_msg">This proposal is much more about the concept than the naming of the replacement</div><div class="gmail_msg">function.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">extension Bool {</div><div class="gmail_msg"> /// If `self == true`, returns `t`, otherwise, returns `f`.</div><div class="gmail_msg"> func transformed<T>(true t: @autoclosure () -> T, false f: @autoclosure () -> T) -> T {</div><div class="gmail_msg"> if self {</div><div class="gmail_msg"> return t()</div><div class="gmail_msg"> } else {</div><div class="gmail_msg"> return f() </div><div class="gmail_msg"> }</div><div class="gmail_msg"> }</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> func when<T>(true t: @autoclosure () -> T, false f: @autoclosure () -> T) -> T {</div><div class="gmail_msg"> ...</div><div class="gmail_msg"> }</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> func if<T>(true t: @autoclosure () -> T, false f: @autoclosure () -> T) -> T {</div><div class="gmail_msg"> ...</div><div class="gmail_msg"> }</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> func if<T>(then t: @autoclosure () -> T, else f: @autoclosure () -> T) -> T {</div><div class="gmail_msg"> ...</div><div class="gmail_msg"> }</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Only one of these should be chosen. We're not proposing adding multiple</div><div class="gmail_msg">functions that achieve the same thing.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Example usage:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">let a = 10</div><div class="gmail_msg">let b = 20</div><div class="gmail_msg">_ = (a < b).transformed(true: "foo", false: "bar")</div><div class="gmail_msg">_ = (a < b).when(true: "foo", false: "bar")</div><div class="gmail_msg">_ = (a < b).if(true: "foo", false: "bar")</div><div class="gmail_msg">_ = (a < b).if(then: "foo", else: "bar")</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#impact-on-existing-code" class="gmail_msg" target="_blank">Impact on existing code</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This proposal is breaking and would require migration.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#alternatives-considered" class="gmail_msg" target="_blank">Alternatives considered</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Simplest alternative: we could leave the ternary operator as is and not</div><div class="gmail_msg">introduce any new concepts.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It'd also be possible to add an `if then else` Haskell-esque expression.</div><div class="gmail_msg">This would have the disadvantages of still needing special handling by the</div><div class="gmail_msg">compiler. Since this proposal's intention is partially to remove compiler</div><div class="gmail_msg">complexity, this would be counterproductive and would probably confuse new</div><div class="gmail_msg">users in a similar way to how `?:` does.</div></div><div class="gmail_msg"><br class="gmail_msg"></div></div><br class="gmail_msg"></div></div><span class="m_-9185505750568932943gmail- gmail_msg">_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
<br class="gmail_msg"></span></blockquote></div><br class="gmail_msg"></div>
<br class="gmail_msg">_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
<br class="gmail_msg"></blockquote></div><br class="gmail_msg"></div></div>
</div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div></div>_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>