Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Xiaodi Wu via swift-evolution]

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...

On Fri, Oct 28, 2016 at 5:56 PM Soroush Khanlou via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 from me as well.
>
> 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.
>
> 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.
>
> 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.
>
> Soroush
>
> On Oct 26, 2016, at 11:42 AM, Joshua Alvarado via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> -1
>
> 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.
>
> Alvarado, Joshua
>
> On Oct 26, 2016, at 9:12 AM, Mark Sands via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Strong *+1* from me.
>
> 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.
>
> 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.
>
> Mark
>
> On Wed, Oct 26, 2016 at 8:52 AM, Mike Kasianowicz via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I like the idea in theory, but I also like the existing ternary operator.
> Could some of this be accomplished without drastic changes?
>
> Some alternative ideas-
>
> 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".
>
> 2) Make it a binary operator with autoclosure tuple on the RHS (is it
> possible to put autoclosure within a tuple?):
>
> public static func ?(_ value: Bool, _ branches: (_ t: @autoclosure ()
> -> T, _ f: @autoclosure () -> T)) -> T {
> if value {
> return branches.t()
> } else {
> return branches.f()
> }
> }
>
>
>
> On Tue, Oct 25, 2016 at 11:51 PM, Charlotte Angela Tortorella via
> swift-evolution  wrote:
>
> 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.
>
> 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.
>
> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c
>
> Replace the `?:` operator with an in-language function
>
> Proposal: TBD
> Author: [Charlotte Tortorella](https://github.com/qata)
> Editor: [Soroush Khanlou](https://github.com/khanlou)
> Review Manager: TBD
> Status: TBD
>
> Introduction
> 
>
> The ternary operator in Swift was added early in development, as a holdover
> from C.  This document is an attempt to provide a clear look at the ternary
> operator without the baggage of the languages that came before, and comes
> to the conclusion that we should deprecate and remove the ternary operator
> in favor of an extension to `Bool`.
>
> As a quick refresher, here's what the ternary operator looks like:
>

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Soroush Khanlou via swift-evolution]

+1 from me as well.

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.

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.

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.

Soroush

> On Oct 26, 2016, at 11:42 AM, Joshua Alvarado via swift-evolution 
>  wrote:
> 
> -1
> 
> 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. 
> 
> Alvarado, Joshua
> 
> On Oct 26, 2016, at 9:12 AM, Mark Sands via swift-evolution 
> > wrote:
> 
>> Strong +1 from me.
>> 
>> 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.
>> 
>> 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.
>> 
>> Mark
>> 
>> On Wed, Oct 26, 2016 at 8:52 AM, Mike Kasianowicz via swift-evolution 
>> > wrote:
>> I like the idea in theory, but I also like the existing ternary operator. 
>> Could some of this be accomplished without drastic changes?
>> 
>> Some alternative ideas-
>> 
>> 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".
>> 
>> 2) Make it a binary operator with autoclosure tuple on the RHS (is it 
>> possible to put autoclosure within a tuple?):
>> 
>> public static func ?(_ value: Bool, _ branches: (_ t: @autoclosure () -> 
>> T, _ f: @autoclosure () -> T)) -> T {
>> if value {
>> return branches.t()
>> } else {
>> return branches.f()
>> }
>> }
>> 
>> 
>> 
>> On Tue, Oct 25, 2016 at 11:51 PM, Charlotte Angela Tortorella via 
>> swift-evolution > > wrote:
>> 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.
>> 
>> 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.
>> 
>> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c 
>> 
>> 
>> Replace the `?:` operator with an in-language function
>> 
>> Proposal: TBD
>> Author: [Charlotte Tortorella](https://github.com/qata 
>> )
>> Editor: [Soroush Khanlou](https://github.com/khanlou 
>> )
>> Review Manager: TBD
>> Status: TBD
>> 
>> Introduction 
>> 
>> 
>> The ternary operator in Swift was added early in development, as a holdover
>> from C.  This document is an attempt to provide a clear look at the ternary
>> operator without the baggage of the languages that came before, and comes
>> to the conclusion that we should deprecate and remove the ternary operator
>> in favor of an extension to `Bool`.
>> 
>> As a quick refresher, here's what the ternary operator looks like:
>> 
>> let a = 10
>> let b = 20
>> // If a is less than b, sets e to "foo", else sets e to "bar"
>> let e = a < b ? "foo" : "bar"
>> 
>> Advantages of The Ternary Operator 
>> 

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Jonathan Hull via swift-evolution]

-1 to replacing this with the functions mentioned.

At some point, I would like to see an operator which lifts a value into an 
optional based on a boolean value (basically the opposite of ??).  That is it 
is either the value or nil based on some boolean value.  If we use ‘?’ as a 
binary operator which does this:

let optional = boolVal ? value  //optional is value if boolVal is true, 
otherwise it is nil

…then the behavior of the Ternary operator behavior falls out without special 
casing in the compiler (using ‘??' instead of ‘:’):

let answer = boolVal ? “true” ?? “false"

It also allows you to chain ‘else if’ style statements together ad infinum:

let answer = (x ? “one”) ?? ( y ? “two”) ?? “three”


That may be too many question marks (as you can see I had to use parenthesis to 
clarify for myself), so we might want to choose some other similarly terse 
symbol.  I think the core idea is sound though.  I have used it in many DSLs 
(with different syntax: ‘?(bool) “true" | “false"') and it was enormously 
helpful/flexible.

Not sure what the best syntax would be (just throwing out ideas).  Maybe 
something like:

let optional = value.?(boolVal)

let answer = “one”.?(x) ?? “two.?(y) ?? “three"


Even with it though, I would still favor a two-stage replacement, depreciating 
it for a while before removing it.  They could co-exist for as long as needed, 
until it makes sense to simplify the compiler by removing the ternary operator.



Honestly, I would really like to go the other way, adding some sort of terse 
operator which is to switch what the ternary operator is to if.  This would 
basically have the semantics similar to a dictionary, but being an operation.  
Horrible throwaway syntax to get the basic point across:

let answer = value ?{ .small: 5, .medium: 10, .large: 20} //Answer is 
5, 10, or 20 depending upon the value in value

The compiler would force completeness the same way it does with switch.

Thanks,
Jon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Paul Cantrell via swift-evolution]

I’d like to put in a word in appreciate of such a careful presentation of the 
idea. While it doesn’t change the fact that this is out of scope for Swift 4, 
it’s nice to read something so thoughtfully spelled out. Charlotte, I hope 
you’ll keep bringing your ideas.

FWIW, while I rather like the ternary operator, I’m also a fan of promoting 
existing if statements to expressions. I hope that we can revisit that 
discussion in the future.

Cheers,

Paul

> On Oct 25, 2016, at 11:51 PM, Charlotte Angela Tortorella via swift-evolution 
>  wrote:
> 
> 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.
> 
> 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.
> 
> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c 
> 
> 
> Replace the `?:` operator with an in-language function
> 
> Proposal: TBD
> Author: [Charlotte Tortorella](https://github.com/qata 
> )
> Editor: [Soroush Khanlou](https://github.com/khanlou 
> )
> Review Manager: TBD
> Status: TBD
> 
> Introduction 
> 
> 
> The ternary operator in Swift was added early in development, as a holdover
> from C.  This document is an attempt to provide a clear look at the ternary
> operator without the baggage of the languages that came before, and comes
> to the conclusion that we should deprecate and remove the ternary operator
> in favor of an extension to `Bool`.
> 
> As a quick refresher, here's what the ternary operator looks like:
> 
> let a = 10
> let b = 20
> // If a is less than b, sets e to "foo", else sets e to "bar"
> let e = a < b ? "foo" : "bar"
> 
> Advantages of The Ternary Operator 
> 
> 
> The primary advantage of this operator is its terseness and expressive
> capability. It's shorthand for (e.g.):
> 
> let a = 10
> let b = 20
> let e: String
> if a < b {
>   e = "foo"
> } else {
>   e = "bar"
> }
> 
> The second advantage of Swift supporting the ternary operator is continuity
> with C, and other common languages in the extended C family (C++, Objective-C,
> Java, C#, Javascript, etc).  People coming to Swift from these other languages
> may reasonably expect this operator to exist.  That said, there are also
> popular languages which have kept the majority of C operators but dropped the
> ternary operator (e.g. 
> [Go](https://golang.org/doc/faq#Does_Go_have_a_ternary_form 
> ) and 
> [Rust](https://github.com/rust-lang/rfcs/issues/1362 
> )).
> 
> 
> Disadvantages of The Ternary Operator 
> 
> 
> 1. The existence of the ternary operator as a holdover from C is to increase
> the familiarity of the Swift language for C family developers, at the expense
> of newcomers.  Established developers do much better with learning concepts
> than newcomers to programming and probably don't need their hands held
> with this carry over of an operator.
> 
> 2. The ternary operator adds complexity to the compiler, because it requires
> special handling.  It is the only operator that requires two components to
> work (both the `?` and the `:`), it uses a character that is excluded from
> being used in other operators (`:`), and it isn't defined in the standard
> library.
> 
> 3. The ternary operator's usage of `?` can be confusing
> to new users.  Every other instance of `?` is associated with
> `Optional` values.
> 
> 4. The ternary operator uses `:`, which is already a heavily overloaded
> symbol in Swift.  `:` is used in hash tables, type annotations for variables,
> class inheritance, and protocol conformance.
> 
> 5. The ternary operator's short length lends it to being abused in the
> nested ternary operator anti-pattern.  This is similar to the `++` and
> `--` operators, which were removed in Swift 3.  While they worked fine and 
> were
> readable enough when used alone, using them multiple times in a single
> expression like `function(a++, ++a)` made them highly unreadable and
> confusing.
> 
> 6. This operator is only applicable to a single type, `Bool`.
> 
> 7. If the ternary operator weren't in common usage, it would not be proposed
> for Swift.  Higher clarity can be achieved with common language features by
> creating 

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[David Sweeris via swift-evolution]

Oh, yeah, sorry, didn't mean to get so far OT

Sent from my iPhone

> On Oct 27, 2016, at 05:20, Jay Abbott  wrote:
> 
> David,
> 
> You make some good points in favour of explicit support for user-defined 
> ternary operators. You're right that it's a bit clunky without. Probably a 
> discussion for another thread though, and additive so not for phase 1. But 
> perhaps worth a proposal for phase 2?
> 
>> On Thu, 27 Oct 2016 at 09:23 David Sweeris  wrote:
>> 
>>> On Oct 26, 2016, at 21:29, Jay Abbott  wrote:
>>> 
>>> David, you can use two binary operators (or overload the same one twice if 
>>> you want) to create syntax that behaves like a ternary operator.
>>> 
>> 
>> Oh I know, it's just kinda clunky and inefficient sometimes, if you need to 
>> wrap a value in a struct or something simply to avoid ambiguity or enforce 
>> the correct syntax. It's not quite the same thing a ternary operator, but at 
>> one point I'd added `|` as both pre and postfix operators to allow code like 
>> "let y = |x|". The left `|` had to return a `_PartialAbsValueOp` and the 
>> right one had to take the same to invalidate the "let y = |x" or "let y = 
>> x|" syntax, one of which would've otherwise worked (depending on which op 
>> actually called "abs()").
>> 
>> I should've been clearer that I was talking about support for "free form" 
>> operators in general, including ternary ops, so that we don't have to fake 
>> them by declaring some # of traditional pre/in/postfix operators which all 
>> then have to work together (possibly exclusively, depending on the desired 
>> syntax), and might have to pass wrapper types around solely to help explain 
>> your syntax to the compiler.
>> 
>> Thanks for pointing it out, though. That's an easy trick to forget about.
>> 
>> - Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Jay Abbott via swift-evolution]

David,

You make some good points in favour of explicit support for user-defined
ternary operators. You're right that it's a bit clunky without. Probably a
discussion for another thread though, and additive so not for phase 1. But
perhaps worth a proposal for phase 2?

On Thu, 27 Oct 2016 at 09:23 David Sweeris  wrote:

>
> On Oct 26, 2016, at 21:29, Jay Abbott  wrote:
>
> David, you can use two binary operators (or overload the same one twice if
> you want) to create syntax that behaves like a ternary operator.
>
> Oh I know, it's just kinda clunky and inefficient sometimes, if you need
> to wrap a value in a struct or something simply to avoid ambiguity or
> enforce the correct syntax. It's not quite the same thing a ternary
> operator, but at one point I'd added `|` as both pre and postfix operators
> to allow code like "let y = |x|". The left `|` had to return a
> `_PartialAbsValueOp` and the right one had to take the same to invalidate
> the "let y = |x" or "let y = x|" syntax, one of which would've otherwise
> worked (depending on which op actually called "abs()").
>
> I should've been clearer that I was talking about support for "free form"
> operators in general, including ternary ops, so that we don't have to fake
> them by declaring some # of traditional pre/in/postfix operators which all
> then have to work together (possibly exclusively, depending on the desired
> syntax), and might have to pass wrapper types around solely to help explain
> your syntax to the compiler.
>
> Thanks for pointing it out, though. That's an easy trick to forget about.
>
> - Dave Sweeris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[David Sweeris via swift-evolution]

> On Oct 26, 2016, at 21:29, Jay Abbott  wrote:
> 
> David, you can use two binary operators (or overload the same one twice if 
> you want) to create syntax that behaves like a ternary operator.
> 
Oh I know, it's just kinda clunky and inefficient sometimes, if you need to 
wrap a value in a struct or something simply to avoid ambiguity or enforce the 
correct syntax. It's not quite the same thing a ternary operator, but at one 
point I'd added `|` as both pre and postfix operators to allow code like "let y 
= |x|". The left `|` had to return a `_PartialAbsValueOp` and the right one had 
to take the same to invalidate the "let y = |x" or "let y = x|" syntax, one of 
which would've otherwise worked (depending on which op actually called "abs()").

I should've been clearer that I was talking about support for "free form" 
operators in general, including ternary ops, so that we don't have to fake them 
by declaring some # of traditional pre/in/postfix operators which all then have 
to work together (possibly exclusively, depending on the desired syntax), and 
might have to pass wrapper types around solely to help explain your syntax to 
the compiler.

Thanks for pointing it out, though. That's an easy trick to forget about.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Jay Abbott via swift-evolution]

David, you can use two binary operators (or overload the same one twice if
you want) to create syntax that behaves like a ternary operator.

Here’s an example of using a pair of operators to interpolate between two
CGPoint values:

let interpolatedPoint = p1 <~~ 0.3 ~~> p2

See here

for the code that defines them.

I went for two different operators in the end, but when experimenting I
also tried using the same one, and it works fine because of overloading,
for example:

infix operator ~~> : InterpolationPrecedence
public func ~~> (from: T, alpha: Double) -> (T, Double) {
return (from, alpha)
}
public func ~~> (lhs: (T, Double), rhs: T) -> T {
return lerp(from: lhs.0, to: rhs, alpha: lhs.1)
}let interpolatedPoint = p1 ~~> 0.3 ~~> p2

And as Anton demonstrated earlier, ?: can be emulated the same way. The
errors you would get if you omitted the second operator and third part are
not as useful as they can be with ?:. The compiler can probably do a much
better job of optimising with ?: as a special case, and it’s a common
pattern regardless of syntax, so people would just write their own if it
wasn’t there. So I think it makes sense to have it in the language. And if
it wasn’t already there, I do think that it would be something we should
add (same for ??).
​

On Thu, 27 Oct 2016 at 01:44 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 25, 2016, at 23:51, Charlotte Angela Tortorella via swift-evolution
>  wrote:
>
> Disadvantages of The Ternary Operator
> 
>
> [...]
>
>
> 6. This operator is only applicable to a single type, `Bool`.
>
> [...]
>
>
> Proposed Approach
> 
>
> We should drop the ternary operator in favor of a new extension to `Bool`.
>
>
> I'm not sure proposals should do exactly what they claim is a downside of
> the current approach. Especially when the downside in question is
> inherent to the problem being solved.
>
> FWIW, the only thing I find confusing about the ternary operator is that I
> can't overload it. Being able to define my own ternary operators would be
> great, but I don't have an answer to obvious potential ambiguities.
>
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[David Sweeris via swift-evolution]

> On Oct 25, 2016, at 23:51, Charlotte Angela Tortorella via swift-evolution 
>  wrote:
> 
> Disadvantages of The Ternary Operator
> 
> [...]
> 
> 6. This operator is only applicable to a single type, `Bool`.
> 
> [...]
> 
> Proposed Approach
> 
> We should drop the ternary operator in favor of a new extension to `Bool`.

I'm not sure proposals should do exactly what they claim is a downside of the 
current approach. Especially when the downside in question is inherent to the 
problem being solved.

FWIW, the only thing I find confusing about the ternary operator is that I 
can't overload it. Being able to define my own ternary operators would be 
great, but I don't have an answer to obvious potential ambiguities.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Erica Sadun via swift-evolution]

You and I discussed this at length in iOS Folks, but I'll restate here. I'd be 
against this proposal. I think it adds unnecessary verbosity vs a simple and 
elegant representation. As an inherently functional alternative to 
if-then-else, Swift's ternary form is clear and parsimonious, perfect for 
simple expressions. Converting to a more laborious syntax takes away these 
advantages, and I'd be tempted to write my own operators to mimic their 
functionality rather than use your syntax.

I'm glad you brought the proposal here and thank you for your effort in writing 
it up.

-- E


> On Oct 25, 2016, at 10:51 PM, Charlotte Angela Tortorella via swift-evolution 
>  wrote:
> 
> 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.
> 
> 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.
> 
> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c 
> 
> 
> Replace the `?:` operator with an in-language function

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Mark Sands via swift-evolution]

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.
>
> Preston
>

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.

Ignoring my statement about "leftovers from C" opposition, I *do* 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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[William Sumner via swift-evolution]

> On Oct 26, 2016, at 9:12 AM, Mark Sands via swift-evolution 
>  wrote:
> 
> Strong +1 from me.
> 
> 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.
> 
> 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.


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. 

Preston___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Joshua Alvarado via swift-evolution]

-1

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. 

Alvarado, Joshua

> On Oct 26, 2016, at 9:12 AM, Mark Sands via swift-evolution 
>  wrote:
> 
> Strong +1 from me.
> 
> 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.
> 
> 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.
> 
> Mark
> 
>> On Wed, Oct 26, 2016 at 8:52 AM, Mike Kasianowicz via swift-evolution 
>>  wrote:
>> I like the idea in theory, but I also like the existing ternary operator. 
>> Could some of this be accomplished without drastic changes?
>> 
>> Some alternative ideas-
>> 
>> 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".
>> 
>> 2) Make it a binary operator with autoclosure tuple on the RHS (is it 
>> possible to put autoclosure within a tuple?):
>> 
>> public static func ?(_ value: Bool, _ branches: (_ t: @autoclosure () -> 
>> T, _ f: @autoclosure () -> T)) -> T {
>> if value {
>> return branches.t()
>> } else {
>> return branches.f()
>> }
>> }
>> 
>> 
>> 
>>> On Tue, Oct 25, 2016 at 11:51 PM, Charlotte Angela Tortorella via 
>>> swift-evolution  wrote:
>>> 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.
>>> 
>>> 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.
>>> 
>>> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c
>>> 
>>> Replace the `?:` operator with an in-language function
>>> 
>>> Proposal: TBD
>>> Author: [Charlotte Tortorella](https://github.com/qata)
>>> Editor: [Soroush Khanlou](https://github.com/khanlou)
>>> Review Manager: TBD
>>> Status: TBD
>>> 
>>> Introduction
>>> 
>>> The ternary operator in Swift was added early in development, as a holdover
>>> from C.  This document is an attempt to provide a clear look at the ternary
>>> operator without the baggage of the languages that came before, and comes
>>> to the conclusion that we should deprecate and remove the ternary operator
>>> in favor of an extension to `Bool`.
>>> 
>>> As a quick refresher, here's what the ternary operator looks like:
>>> 
>>> let a = 10
>>> let b = 20
>>> // If a is less than b, sets e to "foo", else sets e to "bar"
>>> let e = a < b ? "foo" : "bar"
>>> 
>>> Advantages of The Ternary Operator
>>> 
>>> The primary advantage of this operator is its terseness and expressive
>>> capability. It's shorthand for (e.g.):
>>> 
>>> let a = 10
>>> let b = 20
>>> let e: String
>>> if a < b {
>>>   e = "foo"
>>> } else {
>>>   e = "bar"
>>> }
>>> 
>>> The second advantage of Swift supporting the ternary operator is continuity
>>> with C, and other common languages in the extended C family (C++, 
>>> Objective-C,
>>> Java, C#, Javascript, etc).  People coming to Swift from these other 
>>> languages
>>> may reasonably expect this operator to exist.  That said, there are also
>>> popular languages which have kept the majority of C operators but dropped 
>>> the
>>> ternary operator (e.g. 
>>> [Go](https://golang.org/doc/faq#Does_Go_have_a_ternary_form) and 
>>> [Rust](https://github.com/rust-lang/rfcs/issues/1362)).
>>> 
>>> 
>>> Disadvantages of The Ternary Operator
>>> 
>>> 1. The existence of the ternary operator as a holdover from C is to increase
>>> the familiarity of the Swift language for C family developers, at the 
>>> expense
>>> of newcomers.  

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Mark Sands via swift-evolution]

Strong *+1* from me.

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.

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.

Mark

On Wed, Oct 26, 2016 at 8:52 AM, Mike Kasianowicz via swift-evolution <
swift-evolution@swift.org> wrote:

> I like the idea in theory, but I also like the existing ternary operator.
> Could some of this be accomplished without drastic changes?
>
> Some alternative ideas-
>
> 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".
>
> 2) Make it a binary operator with autoclosure tuple on the RHS (is it
> possible to put autoclosure within a tuple?):
>
> public static func ?(_ value: Bool, _ branches: (_ t: @autoclosure ()
> -> T, _ f: @autoclosure () -> T)) -> T {
> if value {
> return branches.t()
> } else {
> return branches.f()
> }
> }
>
>
>
> On Tue, Oct 25, 2016 at 11:51 PM, Charlotte Angela Tortorella via
> swift-evolution  wrote:
>
>> 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.
>>
>> 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.
>>
>> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c
>>
>> Replace the `?:` operator with an in-language function
>>
>> Proposal: TBD
>> Author: [Charlotte Tortorella](https://github.com/qata)
>> Editor: [Soroush Khanlou](https://github.com/khanlou)
>> Review Manager: TBD
>> Status: TBD
>>
>> Introduction
>> 
>>
>> The ternary operator in Swift was added early in development, as a
>> holdover
>> from C.  This document is an attempt to provide a clear look at the
>> ternary
>> operator without the baggage of the languages that came before, and comes
>> to the conclusion that we should deprecate and remove the ternary operator
>> in favor of an extension to `Bool`.
>>
>> As a quick refresher, here's what the ternary operator looks like:
>>
>> let a = 10
>> let b = 20
>> // If a is less than b, sets e to "foo", else sets e to "bar"
>> let e = a < b ? "foo" : "bar"
>>
>> Advantages of The Ternary Operator
>> 
>>
>> The primary advantage of this operator is its terseness and expressive
>> capability. It's shorthand for (e.g.):
>>
>> let a = 10
>> let b = 20
>> let e: String
>> if a < b {
>>   e = "foo"
>> } else {
>>   e = "bar"
>> }
>>
>> The second advantage of Swift supporting the ternary operator is
>> continuity
>> with C, and other common languages in the extended C family (C++,
>> Objective-C,
>> Java, C#, Javascript, etc).  People coming to Swift from these other
>> languages
>> may reasonably expect this operator to exist.  That said, there are also
>> popular languages which have kept the majority of C operators but dropped
>> the
>> ternary operator (e.g. [Go](https://golang.org/doc/fa
>> q#Does_Go_have_a_ternary_form) and [Rust](https://github.com/rust
>> -lang/rfcs/issues/1362)).
>>
>>
>> Disadvantages of The Ternary Operator
>> 
>>
>> 1. The existence of the ternary operator as a holdover from C is to
>> increase
>> the familiarity of the Swift language for C family developers, at the
>> expense
>> of newcomers.  Established developers do much better with learning
>> concepts
>> than newcomers to programming and probably don't need their hands held
>> with this carry over of an operator.
>>
>> 2. The ternary operator adds complexity to the compiler, because it
>> requires
>> special handling.  It is the only operator that requires two components to
>> work (both the `?` and the `:`), it uses a character that is excluded from
>> being used in other operators (`:`), and it isn't defined in the standard
>> library.
>>
>> 3. The ternary operator's 

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Mike Kasianowicz via swift-evolution]

I like the idea in theory, but I also like the existing ternary operator.
Could some of this be accomplished without drastic changes?

Some alternative ideas-

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".

2) Make it a binary operator with autoclosure tuple on the RHS (is it
possible to put autoclosure within a tuple?):

public static func ?(_ value: Bool, _ branches: (_ t: @autoclosure () ->
T, _ f: @autoclosure () -> T)) -> T {
if value {
return branches.t()
} else {
return branches.f()
}
}



On Tue, Oct 25, 2016 at 11:51 PM, Charlotte Angela Tortorella via
swift-evolution  wrote:

> 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.
>
> 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.
>
> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c
>
> Replace the `?:` operator with an in-language function
>
> Proposal: TBD
> Author: [Charlotte Tortorella](https://github.com/qata)
> Editor: [Soroush Khanlou](https://github.com/khanlou)
> Review Manager: TBD
> Status: TBD
>
> Introduction
> 
>
> The ternary operator in Swift was added early in development, as a holdover
> from C.  This document is an attempt to provide a clear look at the ternary
> operator without the baggage of the languages that came before, and comes
> to the conclusion that we should deprecate and remove the ternary operator
> in favor of an extension to `Bool`.
>
> As a quick refresher, here's what the ternary operator looks like:
>
> let a = 10
> let b = 20
> // If a is less than b, sets e to "foo", else sets e to "bar"
> let e = a < b ? "foo" : "bar"
>
> Advantages of The Ternary Operator
> 
>
> The primary advantage of this operator is its terseness and expressive
> capability. It's shorthand for (e.g.):
>
> let a = 10
> let b = 20
> let e: String
> if a < b {
>   e = "foo"
> } else {
>   e = "bar"
> }
>
> The second advantage of Swift supporting the ternary operator is continuity
> with C, and other common languages in the extended C family (C++,
> Objective-C,
> Java, C#, Javascript, etc).  People coming to Swift from these other
> languages
> may reasonably expect this operator to exist.  That said, there are also
> popular languages which have kept the majority of C operators but dropped
> the
> ternary operator (e.g. [Go](https://golang.org/doc/
> faq#Does_Go_have_a_ternary_form) and [Rust](https://github.com/
> rust-lang/rfcs/issues/1362)).
>
>
> Disadvantages of The Ternary Operator
> 
>
> 1. The existence of the ternary operator as a holdover from C is to
> increase
> the familiarity of the Swift language for C family developers, at the
> expense
> of newcomers.  Established developers do much better with learning concepts
> than newcomers to programming and probably don't need their hands held
> with this carry over of an operator.
>
> 2. The ternary operator adds complexity to the compiler, because it
> requires
> special handling.  It is the only operator that requires two components to
> work (both the `?` and the `:`), it uses a character that is excluded from
> being used in other operators (`:`), and it isn't defined in the standard
> library.
>
> 3. The ternary operator's usage of `?` can be confusing
> to new users.  Every other instance of `?` is associated with
> `Optional` values.
>
> 4. The ternary operator uses `:`, which is already a heavily overloaded
> symbol in Swift.  `:` is used in hash tables, type annotations for
> variables,
> class inheritance, and protocol conformance.
>
> 5. The ternary operator's short length lends it to being abused in the
> nested ternary operator anti-pattern.  This is similar to the `++` and
> `--` operators, which were removed in Swift 3.  While they worked fine and
> were
> readable enough when used alone, using them multiple times in a single
> expression like `function(a++, ++a)` made them highly unreadable and
> confusing.
>
> 6. This operator is only applicable to a single type, `Bool`.
>
> 7. If the ternary operator weren't in common usage, it would not 

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[David Goodine via swift-evolution]

-1 as well, particularly agreeing with Rimantas that removing something of use 
because it confuses new programmers is not a good motivation.  To paraphrase 
Einstein, “A programming language should be as simple as possible, but no 
simpler.”

-d

> On Oct 26, 2016, at 6:26 AM, Rimantas Liubertas via swift-evolution 
>  wrote:
> 
> 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.
> 
> -1
> 
> A lot of things can and will be confusing for newcomers, that's not the 
> reason to remove them. Being a newbie is a transitional state.
> OTOH, I've never got why ternary is considered especially confusing, for me 
> it never was a problem and I love the terseness of it.
> Only total novices in programming may be surprised by it, but they will be 
> suprised by a lot of things anyway, so ternary is the least of their 
> problems. Those with experiene in other languages will be most likely already 
> familiar with the
> operator.
> Also, many come to Swift from Objective C, which not only has ternary, but 
> also supports a variant where you can use it kind of like ?? in Swift: 
> NSString *other = someString ?: @"default string".
> 
> Removing ?: gains nothing and loses a lot, I'd say.
> 
> Best regards,
> Rimantas
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Rimantas Liubertas via swift-evolution]

>
> 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.
>

-1

A lot of things can and will be confusing for newcomers, that's not the
reason to remove them. Being a newbie is a transitional state.
OTOH, I've never got why ternary is considered especially confusing, for me
it never was a problem and I love the terseness of it.
Only total novices in programming may be surprised by it, but they will be
suprised by a lot of things anyway, so ternary is the least of their
problems. Those with experiene in other languages will be most likely
already familiar with the
operator.
Also, many come to Swift from Objective C, which not only has ternary, but
also supports a variant where you can use it kind of like ?? in Swift:
NSString *other = someString ?: @"default string".

Removing ?: gains nothing and loses a lot, I'd say.

Best regards,
Rimantas
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Anton Zhilin via swift-evolution]

infix operator ♠️ : LogicalDisjunctionPrecedenceinfix operator ♥ :
LogicalDisjunctionPrecedence
func ♠️(lhs: Bool, rhs: @autoclosure () throws -> T) rethrows -> T? {
if lhs { return rhs() } else { return nil }
}func ♥(lhs: T?, rhs: @autoclosure () throws -> T) rethrows -> T {
return lhs ?? rhs
}
// Equivalent statements:
condition() ? first() : second()
condition() ♠️ first() ♥ second()

By removal of ?:, we could simplify our system of operators and prevent
some ternary-related bugs/unexpected stuff. We could modify reserved
operators to allow ? instead of ♠️ and : instead of ♥.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 25, 2016, at 9:51 PM, Charlotte Angela Tortorella via swift-evolution 
>  wrote:
> 
> 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.
> 

You state the issue beautifully. Previous attempts have been "Complete mess" I 
agree. This is a commonly proposed feature and your solution unfortunately is 
not new. :( 

Replace ?: ternary operator: Definitely magical, but it serves a very important 
use-case for terse selection of different values. Proposals for alternatives 
have been intensely discussed, but none have been "better enough" for it to 
make sense to diverge from the precedent established by the C family of 
languages.



> 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.
> 
> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c
> 
> Replace the `?:` operator with an in-language function
> 
> Proposal: TBD
> Author: [Charlotte Tortorella](https://github.com/qata)
> Editor: [Soroush Khanlou](https://github.com/khanlou)
> Review Manager: TBD
> Status: TBD
> 
> Introduction
> 
> The ternary operator in Swift was added early in development, as a holdover
> from C.  This document is an attempt to provide a clear look at the ternary
> operator without the baggage of the languages that came before, and comes
> to the conclusion that we should deprecate and remove the ternary operator
> in favor of an extension to `Bool`.
> 
> As a quick refresher, here's what the ternary operator looks like:
> 
> let a = 10
> let b = 20
> // If a is less than b, sets e to "foo", else sets e to "bar"
> let e = a < b ? "foo" : "bar"
> 
> Advantages of The Ternary Operator
> 
> The primary advantage of this operator is its terseness and expressive
> capability. It's shorthand for (e.g.):
> 
> let a = 10
> let b = 20
> let e: String
> if a < b {
>   e = "foo"
> } else {
>   e = "bar"
> }
> 
> The second advantage of Swift supporting the ternary operator is continuity
> with C, and other common languages in the extended C family (C++, Objective-C,
> Java, C#, Javascript, etc).  People coming to Swift from these other languages
> may reasonably expect this operator to exist.  That said, there are also
> popular languages which have kept the majority of C operators but dropped the
> ternary operator (e.g. 
> [Go](https://golang.org/doc/faq#Does_Go_have_a_ternary_form) and 
> [Rust](https://github.com/rust-lang/rfcs/issues/1362)).
> 
> 
> Disadvantages of The Ternary Operator
> 
> 1. The existence of the ternary operator as a holdover from C is to increase
> the familiarity of the Swift language for C family developers, at the expense
> of newcomers.  Established developers do much better with learning concepts
> than newcomers to programming and probably don't need their hands held
> with this carry over of an operator.
> 
> 2. The ternary operator adds complexity to the compiler, because it requires
> special handling.  It is the only operator that requires two components to
> work (both the `?` and the `:`), it uses a character that is excluded from
> being used in other operators (`:`), and it isn't defined in the standard
> library.
> 
> 3. The ternary operator's usage of `?` can be confusing
> to new users.  Every other instance of `?` is associated with
> `Optional` values.
> 
> 4. The ternary operator uses `:`, which is already a heavily overloaded
> symbol in Swift.  `:` is used in hash tables, type annotations for variables,
> class inheritance, and protocol conformance.
> 
> 5. The ternary operator's short length lends it to being abused in the
> nested ternary operator anti-pattern.  This is similar to the `++` and
> `--` operators, which were removed in Swift 3.  While they worked fine and 
> were
> readable enough when used alone, using them multiple times in a single
> expression like `function(a++, ++a)` made them highly unreadable and
> confusing.
> 
> 6. This operator is only applicable to a single type, `Bool`.
> 
> 7. If the ternary operator weren't in common usage, it would not be proposed
> for Swift.  Higher clarity can be achieved with common language features by
> creating an extension to `Bool`.
> 
> 8. The ternary operator was created for and is much more suited to a language
> like C, where there were no generics and as such no alternative to an
> unintuitive operator.
> 
> 9. Several other modern languages, like Rust and Go discussed earlier, have
> eschewed the usage of the ternary operator entirely.  Other languages that 
> have
> special constructs similar to `?:`, such as `if then else` in Haskell have
> [discussed removing 
> 

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 26 Oct 2016, at 06:56, Charlotte Tortorella via swift-evolution 
>  wrote:
> 
> Hi Chris,
> 
> I see, well with that in mind the proposal does set out how ?: is harmful to 
> comprehension of code for new programmers and I hope the pros and cons of 
> keeping it are thoroughly vetted. 
> 

They will be throughly vetted as any request is, but 1) I think the operator in 
question is easier to reason about that the alternative provided 2) this 
operator is not even in the league of the elements of the language which are 
important but may let you puzzled at first (good luck with explaining Swift 
unique take on protocol extension default methods to name one) and 3) I do not 
share a latent distaste for what C languages do and feel a need to distance 
ourselves from it (I would have kept the C style for loop, so I may not be the 
best one to ask about it ;)... or seen as things brewing when people argue 
about who is holier... I mean Swiftier and resulting Orthodoxy wars :P).

> Regards,
> Charlotte
> 
>> On 26 Oct. 2016, at 16:52, Chris Lattner  wrote:
>> 
>> 
 On Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella via 
 swift-evolution  wrote:
 
  Not a replacement for the Swift 4 source stability goal.
>>> 
>>> 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.
>> 
>> Hi Charlotte,
>> 
>> Swift 4 has a strong source level compatibility goal.  This is explained in 
>> the main swift-evolution page and also in the proposal template:
>> https://github.com/apple/swift-evolution/blob/master/-template.md
>> 
>> "Relative to the Swift 3 evolution process, the source compatibility 
>> requirements for Swift 4 are much more stringent: we should only break 
>> source compatibility if the Swift 3 constructs were actively harmful in some 
>> way, the volume of affected Swift 3 code is relatively small, and we can 
>> provide source compatibility (in Swift 3 compatibility mode) and migration.”
>> 
>> I agree with you that a migrator could handle this change, but such a 
>> significant source breaking change still needs major justification for doing 
>> so.  Further in the Swift 3 timeframe, this very topic was hotly debated by 
>> the folks who wanted to turn the if statement into an expression 
>> (eliminating the need for the ?: operator).
>> 
>> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Charlotte Tortorella via swift-evolution]

Hi Chris,

I see, well with that in mind the proposal does set out how ?: is harmful to 
comprehension of code for new programmers and I hope the pros and cons of 
keeping it are thoroughly vetted. 

Regards,
Charlotte

> On 26 Oct. 2016, at 16:52, Chris Lattner  wrote:
> 
> 
>>> On Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella via 
>>> swift-evolution  wrote:
>>> 
>>>  Not a replacement for the Swift 4 source stability goal.
>> 
>> 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.
> 
> Hi Charlotte,
> 
> Swift 4 has a strong source level compatibility goal.  This is explained in 
> the main swift-evolution page and also in the proposal template:
> https://github.com/apple/swift-evolution/blob/master/-template.md
> 
> "Relative to the Swift 3 evolution process, the source compatibility 
> requirements for Swift 4 are much more stringent: we should only break source 
> compatibility if the Swift 3 constructs were actively harmful in some way, 
> the volume of affected Swift 3 code is relatively small, and we can provide 
> source compatibility (in Swift 3 compatibility mode) and migration.”
> 
> I agree with you that a migrator could handle this change, but such a 
> significant source breaking change still needs major justification for doing 
> so.  Further in the Swift 3 timeframe, this very topic was hotly debated by 
> the folks who wanted to turn the if statement into an expression (eliminating 
> the need for the ?: operator).
> 
> -Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Chris Lattner via swift-evolution]

> On Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella via swift-evolution 
>  wrote:
> 
>>  Not a replacement for the Swift 4 source stability goal.
> 
> 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.

Hi Charlotte,

Swift 4 has a strong source level compatibility goal.  This is explained in the 
main swift-evolution page and also in the proposal template:
https://github.com/apple/swift-evolution/blob/master/-template.md 


"Relative to the Swift 3 evolution process, the source compatibility 
requirements for Swift 4 are much more stringent: we should only break source 
compatibility if the Swift 3 constructs were actively harmful in some way, the 
volume of affected Swift 3 code is relatively small, and we can provide source 
compatibility (in Swift 3 compatibility mode) and migration.”

I agree with you that a migrator could handle this change, but such a 
significant source breaking change still needs major justification for doing 
so.  Further in the Swift 3 timeframe, this very topic was hotly debated by the 
folks who wanted to turn the if statement into an expression (eliminating the 
need for the ?: operator).

-Chris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Austin Zheng via swift-evolution]

> On Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella 
>  wrote:
> 
>>  Not a replacement for the Swift 4 source stability goal.
> 
> 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.

It has both.

>From 
>https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
> 
>

"For Swift 4, the primary goals are to deliver on the promise of source 
stability from 3.0 on, and to provide ABI stability for the standard library."

> 
>> 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.
> 
> 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".

Swift is as much a language for professional programmers as it is for learners. 
The interests of both must be balanced against each other.

> 
>> I don't agree that any of your functions are more readable than "?:"
> 
> A function that explicitly states what is being returned for certain states 
> of the `Bool` are implicitly more readable than nothing at all.

Once you learn what '?:' does, something which is not conceptually difficult by 
any means, you don't need to be reminded what is being returned.

> 
>> to any significantly greater degree than a `plus()` function would be more 
>> readable than `+`
> 
> `+` is a familiar mathematical concept and conveys its meaning to the 
> layperson quite well. `?:` has no such analogue and conveys nothing to the 
> layperson.

'?:' is a familiar concept to anyone who has experience with the C family 
languages. There are many 'new to Swift' programmers, just as there are many 
'new to programming' Swift programmers.

> 
>> `??` is another magic operator, one that has far less prior art than `?:`; 
>> why not kill that one first?
> 
> Prior art is no guarantor of quality, case in point `?:`.

Prior art (specifically, familiarity to programmers from C-family languages) is 
the explicit reason for many, many "sub-optimal" decisions Swift made, like 
calling ADTs 'enums' and supporting both 'default' and 'case _' as the catchall 
case in switch statements. You can do a search through the mailing list 
archives if you want to see Chris Lattner talk about this, although I certainly 
won't blame you if you don't want to dig through the archives; it's a pity 
gmane is dead.

> 
> 
>> On 26 Oct. 2016, at 4:20 pm, Austin Zheng > > wrote:
>> 
>> 
>>> On Oct 25, 2016, at 10:13 PM, Charlotte Angela Tortorella 
>>> > 
>>> wrote:
>>> 
>>> Addressing breaking source code: this is something that an auto migrator 
>>> could extremely easily be written for.
>> 
>> Auto migrators are:
>> - Specific to Xcode, and therefore OS X Swift development using a very 
>> specific toolchain
>> - Less than reliable for large projects
>> - Not a replacement for the Swift 4 source stability goal.
>> 
>>> 
>>> 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.
>> 
>> 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.
>> 
>>> 
>>> 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 `?:`.
>> 
>> 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?
>> 
>>> 
>>> Addressing your "finally", you've completely missed the argument about 
>>> removing complexity from the compiler, considering how `?:` requires 
>>> special handling.
>> 
>> I don't think it's a worthwhile tradeoff. We had 

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Charlotte Angela Tortorella via swift-evolution]

>  Not a replacement for the Swift 4 source stability goal.

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.

> 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.

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".

> I don't agree that any of your functions are more readable than "?:"

A function that explicitly states what is being returned for certain states of 
the `Bool` are implicitly more readable than nothing at all.

> to any significantly greater degree than a `plus()` function would be more 
> readable than `+`

`+` is a familiar mathematical concept and conveys its meaning to the layperson 
quite well. `?:` has no such analogue and conveys nothing to the layperson.

> `??` is another magic operator, one that has far less prior art than `?:`; 
> why not kill that one first?

Prior art is no guarantor of quality, case in point `?:`.


> On 26 Oct. 2016, at 4:20 pm, Austin Zheng  wrote:
> 
> 
>> On Oct 25, 2016, at 10:13 PM, Charlotte Angela Tortorella 
>> > 
>> wrote:
>> 
>> Addressing breaking source code: this is something that an auto migrator 
>> could extremely easily be written for.
> 
> Auto migrators are:
> - Specific to Xcode, and therefore OS X Swift development using a very 
> specific toolchain
> - Less than reliable for large projects
> - Not a replacement for the Swift 4 source stability goal.
> 
>> 
>> 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.
> 
> 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.
> 
>> 
>> 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 `?:`.
> 
> 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?
> 
>> 
>> Addressing your "finally", you've completely missed the argument about 
>> removing complexity from the compiler, considering how `?:` requires special 
>> handling.
> 
> 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.
> 
>> 
>>> On 26 Oct. 2016, at 4:04 pm, Austin Zheng >> > wrote:
>>> 
>>> 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.
>>> 
>>> That aside, I don't agree with the arguments that the ternary operator is 
>>> confusing.
>>> 
>>> 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`.
>>> 
>>> 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.
>>> 
>>> 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?
>>> 
>>> Best,
>>> Austin
>>> 
 On Oct 25, 2016, at 9:51 PM, Charlotte Angela 

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Austin Zheng via swift-evolution]

> On Oct 25, 2016, at 10:13 PM, Charlotte Angela Tortorella 
>  wrote:
> 
> Addressing breaking source code: this is something that an auto migrator 
> could extremely easily be written for.

Auto migrators are:
- Specific to Xcode, and therefore OS X Swift development using a very specific 
toolchain
- Less than reliable for large projects
- Not a replacement for the Swift 4 source stability goal.

> 
> 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.

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.

> 
> 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 `?:`.

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?

> 
> Addressing your "finally", you've completely missed the argument about 
> removing complexity from the compiler, considering how `?:` requires special 
> handling.

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.

> 
>> On 26 Oct. 2016, at 4:04 pm, Austin Zheng > > wrote:
>> 
>> 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.
>> 
>> That aside, I don't agree with the arguments that the ternary operator is 
>> confusing.
>> 
>> 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`.
>> 
>> 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.
>> 
>> 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?
>> 
>> Best,
>> Austin
>> 
>>> On Oct 25, 2016, at 9:51 PM, Charlotte Angela Tortorella via 
>>> swift-evolution >> > wrote:
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c 
>>> 
>>> 
>>> Replace the `?:` operator with an in-language function
>>> 
>>> Proposal: TBD
>>> Author: [Charlotte Tortorella](https://github.com/qata 
>>> )
>>> Editor: [Soroush Khanlou](https://github.com/khanlou 
>>> )
>>> Review Manager: TBD
>>> Status: TBD
>>> 
>>> Introduction 
>>> 
>>> 
>>> The ternary operator in Swift was added early in development, as a holdover
>>> from C.  This document is an attempt to provide a clear look at the ternary
>>> operator without the baggage of the languages that came before, and comes
>>> to the conclusion that we should deprecate and remove the ternary operator
>>> in favor of an extension to `Bool`.
>>> 
>>> As a quick refresher, here's what the ternary operator looks like:
>>> 
>>> let a = 10
>>> let b = 20
>>> // If a is 

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Charlotte Angela Tortorella via swift-evolution]

Addressing breaking source code: this is something that an auto migrator could 
extremely easily be written for.

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.

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 
`?:`.

Addressing your "finally", you've completely missed the argument about removing 
complexity from the compiler, considering how `?:` requires special handling.

> On 26 Oct. 2016, at 4:04 pm, Austin Zheng  wrote:
> 
> 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.
> 
> That aside, I don't agree with the arguments that the ternary operator is 
> confusing.
> 
> 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`.
> 
> 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.
> 
> 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?
> 
> Best,
> Austin
> 
>> On Oct 25, 2016, at 9:51 PM, Charlotte Angela Tortorella via swift-evolution 
>> > wrote:
>> 
>> 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.
>> 
>> 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.
>> 
>> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c 
>> 
>> 
>> Replace the `?:` operator with an in-language function
>> 
>> Proposal: TBD
>> Author: [Charlotte Tortorella](https://github.com/qata 
>> )
>> Editor: [Soroush Khanlou](https://github.com/khanlou 
>> )
>> Review Manager: TBD
>> Status: TBD
>> 
>> Introduction 
>> 
>> 
>> The ternary operator in Swift was added early in development, as a holdover
>> from C.  This document is an attempt to provide a clear look at the ternary
>> operator without the baggage of the languages that came before, and comes
>> to the conclusion that we should deprecate and remove the ternary operator
>> in favor of an extension to `Bool`.
>> 
>> As a quick refresher, here's what the ternary operator looks like:
>> 
>> let a = 10
>> let b = 20
>> // If a is less than b, sets e to "foo", else sets e to "bar"
>> let e = a < b ? "foo" : "bar"
>> 
>> Advantages of The Ternary Operator 
>> 
>> 
>> The primary advantage of this operator is its terseness and expressive
>> capability. It's shorthand for (e.g.):
>> 
>> let a = 10
>> let b = 20
>> let e: String
>> if a < b {
>>   e = "foo"
>> } else {
>>   e = "bar"
>> }
>> 
>> The second advantage of Swift supporting the ternary operator is continuity
>> with C, and other common languages in the extended C family (C++, 
>> Objective-C,
>> Java, C#, Javascript, etc).  People coming to Swift from these other 
>> languages
>> may reasonably expect this operator to exist.  That said, there are also
>> popular languages which have kept the majority of C operators but dropped the
>> ternary operator (e.g. 
>> [Go](https://golang.org/doc/faq#Does_Go_have_a_ternary_form 
>> ) and 
>> [Rust](https://github.com/rust-lang/rfcs/issues/1362 
>> )).
>> 
>> 
>> Disadvantages of The Ternary Operator 
>> 
>> 
>> 1. The existence of the ternary operator as a holdover from C is to increase
>> the familiarity of the Swift language for C family 

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Austin Zheng via swift-evolution]

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.

That aside, I don't agree with the arguments that the ternary operator is 
confusing.

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`.

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.

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?

Best,
Austin

> On Oct 25, 2016, at 9:51 PM, Charlotte Angela Tortorella via swift-evolution 
>  wrote:
> 
> 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.
> 
> 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.
> 
> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c 
> 
> 
> Replace the `?:` operator with an in-language function
> 
> Proposal: TBD
> Author: [Charlotte Tortorella](https://github.com/qata 
> )
> Editor: [Soroush Khanlou](https://github.com/khanlou 
> )
> Review Manager: TBD
> Status: TBD
> 
> Introduction 
> 
> 
> The ternary operator in Swift was added early in development, as a holdover
> from C.  This document is an attempt to provide a clear look at the ternary
> operator without the baggage of the languages that came before, and comes
> to the conclusion that we should deprecate and remove the ternary operator
> in favor of an extension to `Bool`.
> 
> As a quick refresher, here's what the ternary operator looks like:
> 
> let a = 10
> let b = 20
> // If a is less than b, sets e to "foo", else sets e to "bar"
> let e = a < b ? "foo" : "bar"
> 
> Advantages of The Ternary Operator 
> 
> 
> The primary advantage of this operator is its terseness and expressive
> capability. It's shorthand for (e.g.):
> 
> let a = 10
> let b = 20
> let e: String
> if a < b {
>   e = "foo"
> } else {
>   e = "bar"
> }
> 
> The second advantage of Swift supporting the ternary operator is continuity
> with C, and other common languages in the extended C family (C++, Objective-C,
> Java, C#, Javascript, etc).  People coming to Swift from these other languages
> may reasonably expect this operator to exist.  That said, there are also
> popular languages which have kept the majority of C operators but dropped the
> ternary operator (e.g. 
> [Go](https://golang.org/doc/faq#Does_Go_have_a_ternary_form 
> ) and 
> [Rust](https://github.com/rust-lang/rfcs/issues/1362 
> )).
> 
> 
> Disadvantages of The Ternary Operator 
> 
> 
> 1. The existence of the ternary operator as a holdover from C is to increase
> the familiarity of the Swift language for C family developers, at the expense
> of newcomers.  Established developers do much better with learning concepts
> than newcomers to programming and probably don't need their hands held
> with this carry over of an operator.
> 
> 2. The ternary operator adds complexity to the compiler, because it requires
> special handling.  It is the only operator that requires two components to
> work (both the `?` and the `:`), it uses a character that is excluded from
> being used in other operators (`:`), and it isn't defined in the standard
> library.
> 
> 3. The ternary operator's usage of `?` can be confusing
> to new users.  Every other instance of `?` is associated with
> `Optional` values.
> 
> 4. The ternary operator uses `:`, which is already a heavily overloaded
> symbol in Swift.  `:` is used in hash tables, type annotations for variables,
> class inheritance, and protocol conformance.
> 
> 5. The ternary operator's short length lends it to being abused in the
> nested ternary operator