<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="">Strong -1. I don't feel like stylistic concerns alone are a good enough reason to introduce a change that will undoubtedly break source compatibility for many, many projects come Swift 4.<div class=""><br class=""></div><div class="">That aside, I don't agree with the arguments that the ternary operator is confusing.</div><div class=""><br class=""></div><div class="">1. If you don't know that it exists, you aren't hampered in writing code. The most straightforward solution, and a perfectly good one, is to use an if-else to assign a value to either a `var` or a `let`.</div><div class=""><br class=""></div><div class="">2. If someone new to Swift thinks `?` and `:` are confusing, I really doubt they will react any better to a generic extension method on a type (which is a primitive in other languages) which takes two "@autoclosure" higher-order function parameters.</div><div class=""><br class=""></div><div class="">Finally, if you don't find any of the arguments above confusing, why force a breaking change by removing ?: instead of just adding the bool extension, especially given the source stability goals of Swift 4 and beyond?</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 25, 2016, at 9:51 PM, Charlotte Angela Tortorella via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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=""><br class=""></div><div class="">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=""><br class=""></div><div class="">gist: <a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c" class="">https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c</a></div><div class=""><br class=""></div><div class=""><div class="">Replace the `?:` operator with an in-language function</div><div class=""><br class=""></div><div class="">Proposal: TBD</div><div class="">Author: [Charlotte Tortorella](<a href="https://github.com/qata" class="">https://github.com/qata</a>)</div><div class="">Editor: [Soroush Khanlou](<a href="https://github.com/khanlou" class="">https://github.com/khanlou</a>)</div><div class="">Review Manager: TBD</div><div class="">Status: TBD</div><div class=""><br class=""></div><div class=""><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#introduction" class="">Introduction</a></div><div class=""><br class=""></div><div class="">The ternary operator in Swift was added early in development, as a holdover</div><div class="">from C. This document is an attempt to provide a clear look at the ternary</div><div class="">operator without the baggage of the languages that came before, and comes</div><div class="">to the conclusion that we should deprecate and remove the ternary operator</div><div class="">in favor of an extension to `Bool`.</div><div class=""><br class=""></div><div class="">As a quick refresher, here's what the ternary operator looks like:</div><div class=""><br class=""></div><div class="">let a = 10</div><div class="">let b = 20</div><div class="">// If a is less than b, sets e to "foo", else sets e to "bar"</div><div class="">let e = a < b ? "foo" : "bar"</div><div class=""><br class=""></div><div class=""><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#advantages-of-the-ternary-operator" class="">Advantages of The Ternary Operator</a></div><div class=""><br class=""></div><div class="">The primary advantage of this operator is its terseness and expressive</div><div class="">capability. It's shorthand for (e.g.):</div><div class=""><br class=""></div><div class="">let a = 10</div><div class="">let b = 20</div><div class="">let e: String</div><div class="">if a < b {</div><div class=""> e = "foo"</div><div class="">} else {</div><div class=""> e = "bar"</div><div class="">}</div><div class=""><br class=""></div><div class="">The second advantage of Swift supporting the ternary operator is continuity</div><div class="">with C, and other common languages in the extended C family (C++, Objective-C,</div><div class="">Java, C#, Javascript, etc). People coming to Swift from these other languages</div><div class="">may reasonably expect this operator to exist. That said, there are also</div><div class="">popular languages which have kept the majority of C operators but dropped the</div><div class="">ternary operator (e.g. [Go](<a href="https://golang.org/doc/faq#Does_Go_have_a_ternary_form" class="">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="">https://github.com/rust-lang/rfcs/issues/1362</a>)).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#disadvantages-of-the-ternary-operator" class="">Disadvantages of The Ternary Operator</a></div><div class=""><br class=""></div><div class="">1. The existence of the ternary operator as a holdover from C is to increase</div><div class="">the familiarity of the Swift language for C family developers, at the expense</div><div class="">of newcomers. Established developers do much better with learning concepts</div><div class="">than newcomers to programming and probably don't need their hands held</div><div class="">with this carry over of an operator.</div><div class=""><br class=""></div><div class="">2. The ternary operator adds complexity to the compiler, because it requires</div><div class="">special handling. It is the only operator that requires two components to</div><div class="">work (both the `?` and the `:`), it uses a character that is excluded from</div><div class="">being used in other operators (`:`), and it isn't defined in the standard</div><div class="">library.</div><div class=""><br class=""></div><div class="">3. The ternary operator's usage of `?` can be confusing</div><div class="">to new users. Every other instance of `?` is associated with</div><div class="">`Optional` values.</div><div class=""><br class=""></div><div class="">4. The ternary operator uses `:`, which is already a heavily overloaded</div><div class="">symbol in Swift. `:` is used in hash tables, type annotations for variables,</div><div class="">class inheritance, and protocol conformance.</div><div class=""><br class=""></div><div class="">5. The ternary operator's short length lends it to being abused in the</div><div class="">nested ternary operator anti-pattern. This is similar to the `++` and</div><div class="">`--` operators, which were removed in Swift 3. While they worked fine and were</div><div class="">readable enough when used alone, using them multiple times in a single</div><div class="">expression like `function(a++, ++a)` made them highly unreadable and</div><div class="">confusing.</div><div class=""><br class=""></div><div class="">6. This operator is only applicable to a single type, `Bool`.</div><div class=""><br class=""></div><div class="">7. If the ternary operator weren't in common usage, it would not be proposed</div><div class="">for Swift. Higher clarity can be achieved with common language features by</div><div class="">creating an extension to `Bool`.</div><div class=""><br class=""></div><div class="">8. The ternary operator was created for and is much more suited to a language</div><div class="">like C, where there were no generics and as such no alternative to an</div><div class="">unintuitive operator.</div><div class=""><br class=""></div><div class="">9. Several other modern languages, like Rust and Go discussed earlier, have</div><div class="">eschewed the usage of the ternary operator entirely. Other languages that have</div><div class="">special constructs similar to `?:`, such as `if then else` in Haskell have</div><div class="">[discussed removing it](<a href="https://wiki.haskell.org/If-then-else#Is_If-Then-Else_so_important.3F" class="">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="">excepting that it's prefixed by `if`, while `?:` has no prefix.</div><div class=""><br class=""></div><div class=""> Example: `if True then 10 else 20`</div><div class=""><br class=""></div><div class="">10. On a more personal and anecdotal note, the ternary operator gave me more</div><div class="">trouble than any other operator when I was first learning how to program.</div><div class="">I’ve also spoken to several other people who expressed similar sentiments</div><div class="">about this operator’s inscrutability.</div><div class=""><br class=""></div><div class=""><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#proposed-approach" class="">Proposed Approach</a></div><div class=""><br class=""></div><div class="">We should drop the ternary operator in favor of a new extension to `Bool`.</div><div class="">There are a few possibilities for the naming of this function. We've provided</div><div class="">four for consideration in this proposal, but are open to other options as well.</div><div class="">This proposal is much more about the concept than the naming of the replacement</div><div class="">function.</div><div class=""><br class=""></div><div class="">extension Bool {</div><div class=""> /// If `self == true`, returns `t`, otherwise, returns `f`.</div><div class=""> func transformed<T>(true t: @autoclosure () -> T, false f: @autoclosure () -> T) -> T {</div><div class=""> if self {</div><div class=""> return t()</div><div class=""> } else {</div><div class=""> return f() </div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class=""> func when<T>(true t: @autoclosure () -> T, false f: @autoclosure () -> T) -> T {</div><div class=""> ...</div><div class=""> }</div><div class=""><br class=""></div><div class=""> func if<T>(true t: @autoclosure () -> T, false f: @autoclosure () -> T) -> T {</div><div class=""> ...</div><div class=""> }</div><div class=""><br class=""></div><div class=""> func if<T>(then t: @autoclosure () -> T, else f: @autoclosure () -> T) -> T {</div><div class=""> ...</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">Only one of these should be chosen. We're not proposing adding multiple</div><div class="">functions that achieve the same thing.</div><div class=""><br class=""></div><div class="">Example usage:</div><div class=""><br class=""></div><div class="">let a = 10</div><div class="">let b = 20</div><div class="">_ = (a < b).transformed(true: "foo", false: "bar")</div><div class="">_ = (a < b).when(true: "foo", false: "bar")</div><div class="">_ = (a < b).if(true: "foo", false: "bar")</div><div class="">_ = (a < b).if(then: "foo", else: "bar")</div><div class=""><br class=""></div><div class=""><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#impact-on-existing-code" class="">Impact on existing code</a></div><div class=""><br class=""></div><div class="">This proposal is breaking and would require migration.</div><div class=""><br class=""></div><div class=""><a href="https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c#alternatives-considered" class="">Alternatives considered</a></div><div class=""><br class=""></div><div class="">Simplest alternative: we could leave the ternary operator as is and not</div><div class="">introduce any new concepts.</div><div class=""><br class=""></div><div class="">It'd also be possible to add an `if then else` Haskell-esque expression.</div><div class="">This would have the disadvantages of still needing special handling by the</div><div class="">compiler. Since this proposal's intention is partially to remove compiler</div><div class="">complexity, this would be counterproductive and would probably confuse new</div><div class="">users in a similar way to how `?:` does.</div></div><div class=""><br class=""></div></div>_______________________________________________<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></blockquote></div><br class=""></div></div></div></body></html>