[Pitch] Replace the ternary operator with an in-language function

[Panajev (Goffredo Marocchi)]

Very well said, thanks :)!

···

Sent from my iPhone

On 26 Oct 2016, at 18:57, Jon Akhtar via swift-evolution <swift-evolution@swift.org> wrote:

I think that we need to get past the “leftovers from C” being a bad thing mindset. Familiar constructs make Swift easier for programmers (its target audience) easier to learn.

Point by point:

Being a holdover from C isn’t a bad thing. We can take things that were useful in C and make them part of Swift. Who said C language elements were a non-goal of Swift. And to the “ternary operator is hard to learn” point. This point gets made over and over in proposals to change Swift, ease of learning is like performance and security – you can never have enough so there is no counter-argument. If you can’t learn the ternary operator, Swift isn’t the language for you, because what are you going to do when you get to generics and higher order functions.
If the ternary operator adds complexity to the compiler then it really isn’t a holdover from C. We have quite a long time to know how to parse it from our C legacy.
See #1, new users are always confused about everything. They don’t stay that way. The language doesn’t need to be tuned to support it’s non-users. Most developers understand the ternary operator, and it is useful to them. Who is this language for?
The “:” appears in other places in the grammar. So what. So do parenthesis and brackets. It is just a token used in a grammar rule as a separator, it doesn’t have a meaning on its own, and it shouldn’t have one that isn’t its function.
So your argument is to make the ternary expression longer to discourage nesting. This is much different than the argument for function(a++, ++a) where order of function parameter evaluation influenced the code, but was not expressed by it. Everything is fully expressed by the ternary operator including order of evaluation.
I see no problem with it being limited to bool. I don’t want Javascript’s “” == false.
What would be proposed (and has been) is the if expression which is more verbose but easier to read
Again, the C hate.
You leave out the reason for those languages to leave out the ternary operator. What was their rationale?
I’m sorry you had a hard time with it. But you learned it, and now you can apply that knowledge to any language that has it. To add to the anecdotal evidence you provided, I did not have a hard time learning it.
I can distill this down to “C is old and not modern so lets get rid of anything from C” and “I had a hard time learning the ternary operator"

Bottom line, most developers know the ternary expression if they come from C, C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different for style reasons. We will be making a niche language, because what you learn isn’t portable to another language like it is if you learn Java, then get a job programming in C#.

From: <swift-evolution-bounces@swift.org> on behalf of Mark Sands via swift-evolution <swift-evolution@swift.org>
Reply-To: Mark Sands <marksands07@gmail.com>
Date: Wednesday, October 26, 2016 at 09:55
To: William Sumner <prestonsumner@me.com>
Cc: Swift-Evolution <swift-evolution@swift.org>
Subject: [External] Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

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.
+ V2 Checkin API
+ V2 Checkout API
+ V2 Get Admission Records [Updated]
+ V2 Get Scan Records
- New SQLite Data File generation
- V2 Get User Events
- V2 Scan Record Submission

- GDO Ticket Purchase Integration API

- V2 Get Ticket Record(s) [New]
- V2 Ticket Creation API [Updated]
- V2 Ticket Info API [New]
- V2 Ticket Transfer API [New]
- V2 Ticket Re-issue API [New]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Haravikk3 (Haravikk)]

While I agree on most of this, I think there is reasonable justification to discuss this on the basis of it using the question-mark; Swift uses the question mark extensively for handling of optionals, so there is an element of confusion present there, it also uses the colon in a somewhat unfamiliar way as well, so it's a twofold oddity in Swift.

That said, I'm not sure replacing it with a function is superior; this is something you can do yourself easily enough if you feel you need to, and which learners can likewise do if they don't know about, or don't like the operator.

So the question really is whether there's an alternative that is similarly concise, and on that I'm not so sure, so I'd lean towards leaving it as it is, but advising people to be careful about where they use it, as its very advantage in size can be a disadvantage in readability, so it should be used with care at all times.

···

On 26 Oct 2016, at 18:57, Jon Akhtar via swift-evolution <swift-evolution@swift.org> wrote:

I think that we need to get past the “leftovers from C” being a bad thing mindset. Familiar constructs make Swift easier for programmers (its target audience) easier to learn.

Point by point:

Being a holdover from C isn’t a bad thing. We can take things that were useful in C and make them part of Swift. Who said C language elements were a non-goal of Swift. And to the “ternary operator is hard to learn” point. This point gets made over and over in proposals to change Swift, ease of learning is like performance and security – you can never have enough so there is no counter-argument. If you can’t learn the ternary operator, Swift isn’t the language for you, because what are you going to do when you get to generics and higher order functions.
If the ternary operator adds complexity to the compiler then it really isn’t a holdover from C. We have quite a long time to know how to parse it from our C legacy.
See #1, new users are always confused about everything. They don’t stay that way. The language doesn’t need to be tuned to support it’s non-users. Most developers understand the ternary operator, and it is useful to them. Who is this language for?
The “:” appears in other places in the grammar. So what. So do parenthesis and brackets. It is just a token used in a grammar rule as a separator, it doesn’t have a meaning on its own, and it shouldn’t have one that isn’t its function.
So your argument is to make the ternary expression longer to discourage nesting. This is much different than the argument for function(a++, ++a) where order of function parameter evaluation influenced the code, but was not expressed by it. Everything is fully expressed by the ternary operator including order of evaluation.
I see no problem with it being limited to bool. I don’t want Javascript’s “” == false.
What would be proposed (and has been) is the if expression which is more verbose but easier to read
Again, the C hate.
You leave out the reason for those languages to leave out the ternary operator. What was their rationale?
I’m sorry you had a hard time with it. But you learned it, and now you can apply that knowledge to any language that has it. To add to the anecdotal evidence you provided, I did not have a hard time learning it.
I can distill this down to “C is old and not modern so lets get rid of anything from C” and “I had a hard time learning the ternary operator"

Bottom line, most developers know the ternary expression if they come from C, C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different for style reasons. We will be making a niche language, because what you learn isn’t portable to another language like it is if you learn Java, then get a job programming in C#.

[Jay]

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
<https://github.com/j-h-a/Animation/blob/develop/Animation/Interpolation.swift&gt;
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 ~~> <T: Interpolatable>(from: T, alpha: Double) -> (T, Double) {
    return (from, alpha)
}
public func ~~> <T: Interpolatable>(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 > <swift-evolution@swift.org> wrote:

Disadvantages of The Ternary Operator
<replace-ternary.md · GitHub;

[...]

6. This operator is only applicable to a single type, `Bool`.

[...]

Proposed Approach
<replace-ternary.md · GitHub;

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

[trs (Thorsten Seitz)]

+1 to Jon's answer.
-1 to the proposal. I have argued in the past for introducing an if-then-else expression instead of the ternary operator but I wouldn't replace it with a clunky function which reduces readability a lot IMHO.

-Thorsten

···

Am 26.10.2016 um 19:57 schrieb Jon Akhtar via swift-evolution <swift-evolution@swift.org>:

I think that we need to get past the “leftovers from C” being a bad thing mindset. Familiar constructs make Swift easier for programmers (its target audience) easier to learn.

Point by point:

Being a holdover from C isn’t a bad thing. We can take things that were useful in C and make them part of Swift. Who said C language elements were a non-goal of Swift. And to the “ternary operator is hard to learn” point. This point gets made over and over in proposals to change Swift, ease of learning is like performance and security – you can never have enough so there is no counter-argument. If you can’t learn the ternary operator, Swift isn’t the language for you, because what are you going to do when you get to generics and higher order functions.
If the ternary operator adds complexity to the compiler then it really isn’t a holdover from C. We have quite a long time to know how to parse it from our C legacy.
See #1, new users are always confused about everything. They don’t stay that way. The language doesn’t need to be tuned to support it’s non-users. Most developers understand the ternary operator, and it is useful to them. Who is this language for?
The “:” appears in other places in the grammar. So what. So do parenthesis and brackets. It is just a token used in a grammar rule as a separator, it doesn’t have a meaning on its own, and it shouldn’t have one that isn’t its function.
So your argument is to make the ternary expression longer to discourage nesting. This is much different than the argument for function(a++, ++a) where order of function parameter evaluation influenced the code, but was not expressed by it. Everything is fully expressed by the ternary operator including order of evaluation.
I see no problem with it being limited to bool. I don’t want Javascript’s “” == false.
What would be proposed (and has been) is the if expression which is more verbose but easier to read
Again, the C hate.
You leave out the reason for those languages to leave out the ternary operator. What was their rationale?
I’m sorry you had a hard time with it. But you learned it, and now you can apply that knowledge to any language that has it. To add to the anecdotal evidence you provided, I did not have a hard time learning it.
I can distill this down to “C is old and not modern so lets get rid of anything from C” and “I had a hard time learning the ternary operator"

Bottom line, most developers know the ternary expression if they come from C, C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different for style reasons. We will be making a niche language, because what you learn isn’t portable to another language like it is if you learn Java, then get a job programming in C#.

From: <swift-evolution-bounces@swift.org> on behalf of Mark Sands via swift-evolution <swift-evolution@swift.org>
Reply-To: Mark Sands <marksands07@gmail.com>
Date: Wednesday, October 26, 2016 at 09:55
To: William Sumner <prestonsumner@me.com>
Cc: Swift-Evolution <swift-evolution@swift.org>
Subject: [External] Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

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.
+ V2 Checkin API
+ V2 Checkout API
+ V2 Get Admission Records [Updated]
+ V2 Get Scan Records
- New SQLite Data File generation
- V2 Get User Events
- V2 Scan Record Submission

- GDO Ticket Purchase Integration API

- V2 Get Ticket Record(s) [New]
- V2 Ticket Creation API [Updated]
- V2 Ticket Info API [New]
- V2 Ticket Transfer API [New]
- V2 Ticket Re-issue API [New]
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Austin (Austin Zheng)]

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 [swift-evolution] Looking back on Swift 3 and ahead to Swift 4

"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 Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella <charlotte.tortorella@icloud.com> wrote:

On 26 Oct. 2016, at 4:20 pm, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

On Oct 25, 2016, at 10:13 PM, Charlotte Angela Tortorella <charlotte.tortorella@icloud.com <mailto:charlotte.tortorella@icloud.com>> 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 <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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: replace-ternary.md · GitHub

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 <replace-ternary.md · GitHub;

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 <replace-ternary.md · GitHub;

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](Frequently Asked Questions (FAQ) - The Go Programming Language) and [Rust](Issues · rust-lang/rfcs · GitHub)).

Disadvantages of The Ternary Operator <replace-ternary.md · GitHub;

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 it](If-then-else - HaskellWiki). `if then else` is identical to the `?:` operator,
excepting that it's prefixed by `if`, while `?:` has no prefix.

Example: `if True then 10 else 20`

10. On a more personal and anecdotal note, the ternary operator gave me more
trouble than any other operator when I was first learning how to program.
I’ve also spoken to several other people who expressed similar sentiments
about this operator’s inscrutability.

Proposed Approach <replace-ternary.md · GitHub;

We should drop the ternary operator in favor of a new extension to `Bool`.
There are a few possibilities for the naming of this function. We've provided
four for consideration in this proposal, but are open to other options as well.
This proposal is much more about the concept than the naming of the replacement
function.

extension Bool {
    /// If `self == true`, returns `t`, otherwise, returns `f`.
    func transformed<T>(true t: @autoclosure () -> T, false f: @autoclosure () -> T) -> T {
        if self {
            return t()
        } else {
            return f()
        }
    }

    func when<T>(true t: @autoclosure () -> T, false f: @autoclosure () -> T) -> T {
      ...
    }

    func if<T>(true t: @autoclosure () -> T, false f: @autoclosure () -> T) -> T {
      ...
    }

    func if<T>(then t: @autoclosure () -> T, else f: @autoclosure () -> T) -> T {
      ...
    }
}

Only one of these should be chosen. We're not proposing adding multiple
functions that achieve the same thing.

Example usage:

let a = 10
let b = 20
_ = (a < b).transformed(true: "foo", false: "bar")
_ = (a < b).when(true: "foo", false: "bar")
_ = (a < b).if(true: "foo", false: "bar")
_ = (a < b).if(then: "foo", else: "bar")

Impact on existing code <replace-ternary.md · GitHub;

This proposal is breaking and would require migration.

Alternatives considered <replace-ternary.md · GitHub;

Simplest alternative: we could leave the ternary operator as is and not
introduce any new concepts.

It'd also be possible to add an `if then else` Haskell-esque expression.
This would have the disadvantages of still needing special handling by the
compiler. Since this proposal's intention is partially to remove compiler
complexity, this would be counterproductive and would probably confuse new
users in a similar way to how `?:` does.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

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/0000-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

···

On Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella via swift-evolution <swift-evolution@swift.org> 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.

[lotte (Charlotte Angela Tortorella)]

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 <clattner@apple.com> wrote:

On Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella via swift-evolution <swift-evolution@swift.org> 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/0000-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

[Chris_Lattner]

I’ll add a couple of more points:

1. This was extensively discussed in the Swift 3 release cycle, in multiple threads, and never went anywhere.
2. Changing this in Swift 4 is extremely unlikely even if there is a good answer, because - unlike in Swift 3 timeframe - any change that breaks source code needs extreme justification of why it is the right long term thing to do. I can’t fathom a rationale for this in the case of the ?: operator. Merely being potentially confusing is not enough.

-Chris

···

On Oct 26, 2016, at 11:54 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

Bottom line, most developers know the ternary expression if they come from C, C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different for style reasons. We will be making a niche language, because what you learn isn’t portable to another language like it is if you learn Java, then get a job programming in C#.

While I agree on most of this, I think there is reasonable justification to discuss this on the basis of it using the question-mark; Swift uses the question mark extensively for handling of optionals, so there is an element of confusion present there, it also uses the colon in a somewhat unfamiliar way as well, so it's a twofold oddity in Swift.

That said, I'm not sure replacing it with a function is superior; this is something you can do yourself easily enough if you feel you need to, and which learners can likewise do if they don't know about, or don't like the operator.

So the question really is whether there's an alternative that is similarly concise, and on that I'm not so sure, so I'd lean towards leaving it as it is, but advising people to be careful about where they use it, as its very advantage in size can be a disadvantage in readability, so it should be used with care at all times.

[David_Sweeris]

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

···

On Oct 26, 2016, at 21:29, Jay Abbott <jay@abbott.me.uk> 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.

[Panajev (Goffredo Marocchi)]

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

···

Sent from my iPhone

On 26 Oct 2016, at 06:56, Charlotte Tortorella via swift-evolution <swift-evolution@swift.org> wrote:

Regards,
Charlotte

On 26 Oct. 2016, at 16:52, Chris Lattner <clattner@apple.com> wrote:

On Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella via swift-evolution <swift-evolution@swift.org> 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/0000-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

[Jay]

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 <davesweeris@mac.com> wrote:

On Oct 26, 2016, at 21:29, Jay Abbott <jay@abbott.me.uk> 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

[David_Sweeris]

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

···

Sent from my iPhone

On Oct 27, 2016, at 05:20, Jay Abbott <jay@abbott.me.uk> 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 <davesweeris@mac.com> wrote:

On Oct 26, 2016, at 21:29, Jay Abbott <jay@abbott.me.uk> 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