<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=""><div class=""></div><blockquote type="cite" class=""><div class=""> Not a replacement for the Swift 4 source stability goal.</div></blockquote><div class=""><br class=""></div>Swift 4 doesn't actually have a source stability goal. It has an ABI stability goal. These are two very different things. ABI is the calling conventions of the language.<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">So, a programmer learns what '?:' means the first time she encounters it and knows what it does for the rest of her life, can recognize it when she sees it in the many other languages which support it, and can take advantage of its terseness if she chooses. I don't see any downsides.</div></div></div></blockquote><div class=""><br class=""></div><div class="">It's still confusing to learn and conveys no meaning by virtue of its symbols. Sure, everyone learns what something does and then knows how to use it, that doesn't change that certain things are less intuitive and create a higher barrier of entry to the language until one can be considered "fluent".</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">I don't agree that any of your functions are more readable than "?:"</div></div></div></blockquote><div class=""><br class=""></div>A function that explicitly states what is being returned for certain states of the `Bool` are implicitly more readable than nothing at all.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">to any significantly greater degree than a `plus()` function would be more readable than `+`</div></div></div></blockquote><div class=""><br class=""></div>`+` is a familiar mathematical concept and conveys its meaning to the layperson quite well. `?:` has no such analogue and conveys nothing to the layperson.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">`??` is another magic operator, one that has far less prior art than `?:`; why not kill that one first?</div></div></div></blockquote><div class=""><br class=""></div>Prior art is no guarantor of quality, case in point `?:`.</div><div class=""><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 26 Oct. 2016, at 4:20 pm, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 25, 2016, at 10:13 PM, Charlotte Angela Tortorella <<a href="mailto:charlotte.tortorella@icloud.com" class="">charlotte.tortorella@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Addressing breaking source code: this is something that an auto migrator could extremely easily be written for.</div></div></blockquote><div class=""><br class=""></div><div class="">Auto migrators are:</div><div class="">- Specific to Xcode, and therefore OS X Swift development using a very specific toolchain</div><div class="">- Less than reliable for large projects</div><div class="">- Not a replacement for the Swift 4 source stability goal.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Addressing your first point, `?:` has the advantage of terseness. Your solution requires a lot of code repetition and invariably a programmer will eventually have to deal with `?:` when interacting with literally anyone else's code.<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">So, a programmer learns what '?:' means the first time she encounters it and knows what it does for the rest of her life, can recognize it when she sees it in the many other languages which support it, and can take advantage of its terseness if she chooses. I don't see any downsides.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">Addressing your second point, `?:` has no function signature. Thus we should be comparing at call-site value. A Bool extension that mentions `true` and `false` in the function signature is far more readable than the magical operator of `?:`.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't agree that any of your functions are more readable than "?:", to any significantly greater degree than a `plus()` function would be more readable than `+`, but that's probably just a matter of taste. `??` is another magic operator, one that has far less prior art than `?:`; why not kill that one first?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">Addressing your "finally", you've completely missed the argument about removing complexity from the compiler, considering how `?:` requires special handling.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't think it's a worthwhile tradeoff. We had a proposal a few months back to remove associated type inference, which would have greatly simplified the type checker and fixed a number of critical bugs. It was rejected due to the impact it would have on developer ergonomics. Compiler complexity is not necessarily a more important goal than user experience.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 26 Oct. 2016, at 4:04 pm, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div 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 class=""><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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>