ternary operator ?: suggestion

[dennislysenko]

I hate to triple-post, but removing ternary seems similar to the 'removing
c-style for loops' proposal that was recently accepted:

apple/swift-evolution/blob/main/proposals/0007-remove-c-style-for-loops.md

To quote:
The C-style for-loop appears to be a mechanical carry-over from C rather
than a genuinely Swift-specific construct. It is rarely used and not very
Swift-like.

You could say the same thing about ternary. Rarely used; not very
Swift-like, conflicting with the use of ? for optionals; seems to be
disliked (rationally or irrationally) by many; and in almost all cases you
can achieve the same exact thing, but ostensibly more readable, with a few
extra lines.

···

On Tue, Dec 15, 2015 at 11:18 AM Dennis Lysenko via swift-evolution < swift-evolution@swift.org> wrote:

Also, +1 to removing ?: ternary in general. It does not match the
atmosphere of Swift. Where you can write:

self.x = a ? b : c
self.y = a ? d : e
self.z = a ? f : g

You could just write

if a {
  self.x = b
  self.y = d
  self.z = f
} else {
  self.x = c
  self.y = e
  self.z = g
}

Now it's easier to scan for what changes when a is true. With
if-expressions, this would scale even better to multiple
conditions/declarations.

On Tue, Dec 15, 2015 at 11:14 AM Dennis Lysenko < > dennis.s.lysenko@gmail.com> wrote:

Can we just have if-expressions and Xcode indent if-statements the way
that Ruby style guides suggest?

let x = if y < 0 {
z * z - 4
} else {
8
}

Works fantastically well in Ruby, for me. Looks a bit strange to the
untrained eye but that went away for me pretty much the first time I wrote
one of these. It's:

- More readable than ternary
- Not shoehorning complex logic onto one line
- All indented to the same indentation level

And we don't have the 80-char line delimiter or length limit in Swift,
with Xcode also using a slightly smaller font size than most other IDEs, so
indentation should not be that much of an issue. Admittedly, ruby style
dictates two-space indentation which makes this type of code slightly
shallower.

On Tue, Dec 15, 2015 at 5:34 AM Al Skipp via swift-evolution < >> swift-evolution@swift.org> wrote:

On 15 Dec 2015, at 06:41, Paul Ossenbruggen via swift-evolution < >>> swift-evolution@swift.org> wrote:

Agreed, I was thinking to I really want turn something that was 2
characters into 10 and will I really be happy with that at the end of the
day. A properly formatted ternary can be quite easy to read, it is when
people get sloppy and try to cram too much into one expression that they
get really hard to follow. For example,

    return (a<b) ? (b<c) ? b : (a<c) ? c : a : (a<c) ? a : (b<c) ? c : b;

If formatted like this becomes easier follow the logic (at least to me):

return a < b
? b < c
? b
: a < c
? c
: a
: a < c
? a
: b < c
? c
: b

I’m happy to make use of the ternary operator, but never in a nested
fashion. It looks neat and succinct on first glance, but is quite
impenetrable to read. I don’t think there’s a way to make such nested
expressions easily comprehensible. Nested ‘if/else/then’ expressions will
be equally bewildering.

On a purely stylistic level I think simple, ‘if/then/else’ expressions,
would have a more Swift vibe to them than the ternary operator. Well, that
would be the case if it didn’t introduce the confusion between expressions
and statements.

I do still however like the Switch Expressions.

I agree. The Switch expression proposal is worth pursuing, it’s
something I’d really like to see in the language. One concern I have is
that it faces the same dilemma of the ‘if’ expression proposal, that is,
how to make the distinction between a statement and an expression
unambiguous?

Here’s a suggestion, it might be terrible (I’ve not had my third cup of
tea of the morning yet), but how about a different keyword? I know, I feel
guilty for the suggestion already, but here it is:

switch == statement
match == expression

The syntax you (@Paul) have already suggested for the feature wouldn’t
change, but instead of ‘switch’, it’d use the ‘match’ keyword for the
expression form. Good, bad, terrible? What do people think?

Al

_______________________________________________
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

[Al_Skipp]

If the ternary operator is removed, but is not replaced with an equivalent expression, so that we must resort to ‘if’ statements, I will cry!

Al

···

On 15 Dec 2015, at 16:18, Dennis Lysenko <dennis.s.lysenko@gmail.com> wrote:

Also, +1 to removing ?: ternary in general. It does not match the atmosphere of Swift. Where you can write:

self.x = a ? b : c
self.y = a ? d : e
self.z = a ? f : g

You could just write

if a {
  self.x = b
  self.y = d
  self.z = f
} else {
  self.x = c
  self.y = e
  self.z = g
}

Now it's easier to scan for what changes when a is true. With if-expressions, this would scale even better to multiple conditions/declarations.

[Chris_Lattner1 (Chris Lattner)]

There are significant differences though: C style for loop is almost never used (and many people chimed in to say that they had *zero* uses in their code), but ternary is widely used. In order to remove ternary, we’d need to have something to replace it with, which is the topic of much of this thread. IMO, in order to consider removing ternary, we’d have to introduce something that is *better* than the current ternary operator first.

-Chris

···

On Dec 15, 2015, at 8:32 AM, Dennis Lysenko via swift-evolution <swift-evolution@swift.org> wrote:

I hate to triple-post, but removing ternary seems similar to the 'removing c-style for loops' proposal that was recently accepted: https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md

To quote:
The C-style for-loop appears to be a mechanical carry-over from C rather than a genuinely Swift-specific construct. It is rarely used and not very Swift-like.

You could say the same thing about ternary. Rarely used; not very Swift-like, conflicting with the use of ? for optionals; seems to be disliked (rationally or irrationally) by many; and in almost all cases you can achieve the same exact thing, but ostensibly more readable, with a few extra lines.

[Rainer_Brockerhoff]

You could say the same thing about ternary. Rarely used;

I seem to use it _a lot_ in C and ObjC and find it more concise that
proposed alternatives. Especially the `?:` variety.

not very Swift-like, conflicting with the use of ? for optionals;

That I don't see, as an isolated `?` with whitespace around is AFAIK not
used for optionals.

seems to be disliked (rationally or irrationally) by many; and in
almost all cases you can achieve the same exact thing, but ostensibly
more readable, with a few extra lines.

But the objective is exactly to say whatever on a single line!

I grant that you should either not nest it, or always use ()s, but that
is true for all boolean operators IMHO.

···

On 12/15/15 14:32, Dennis Lysenko wrote:

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."

Solipsism Gradient

[possen (Paul Ossenbruggen)]

I think pick…from may address many of the negatives listed by Chris. with the if..then..else approach.

The closest proposal I’ve seen is the “if cond then value1 else value2” syntax, however that has serious (IMO) problems:

- It is substantially more verbose than ?:, so much so that it obscures the logic that was trying to be captured. Simple things like this become swallowed in syntax:
  let x = cond ? 4 : 8
  let x = if cond then 4 else 8

this suggestion would still be longer, you can’t beat 2 chars. It is shorter than if..then..else though. Not sure there are any good options that can beat the conciseness of the ternary without replacing it with more syntax.

let x = pick cond from 4, 8

- Because it looks like an if statement, people will end up writing it like:

let x = if cond then
    some_long_expression
     else
    some_other_long_expression

- it only accepts expressions, not statements. The way it is flowed makes it look like a statement.
- It is now force indenting a lot, which just looks weird and isn’t precedented in Swift.

By having a new keyword, we can define the format and there is no prior connotation with it.

When this happens, we now have new problems:
- At a glance, it “looks” like an if statement, but it is semantically different.

Since it is a new it will always look like something that handles expressions only.

Also this pick…from statement can be extended to handle switch expressions as well. So it is consistent way to do different expressions based upon an input.

Some downsides:
new keyword
no prior history with other programming languages.

···

On Dec 15, 2015, at 4:31 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

Been thinking a bit:

Perhaps a new expression is in order. “Pick” this has a form like this. Param is a selector This only allows expressions

It has two forms:

To replace ternary:

let x = pick val from "abc", "cdef"

To replace switch expressions. The cases follows existing rules for switch cases.

let y = pick val from cases .Red: 1, .Green: 2, .Blue: 3

This keeps the notion of expressions and statements quite separate. It avoids syntax confusion. It reads clear. It is fairy concise. It uses a straight forward pattern for both forms of expression.

- Paul

On Dec 15, 2015, at 2:06 PM, Charles Constant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1 bigtime for the assignment via Switch proposal

I think someone here made the argument, I can't remember who, that it would be confusing for beginners. I think exactly the opposite.

Once a new programmer has learned how to write a normal Switch statement, they'll be able to "leverage" the same concept and map values using the Switch assignment. Some might even try it on their on own, through experimentation, to see if it will work. It's such a pleasant experience when you try something in a language that seems consistent with what you already know, and discover "cool, it works!"

At the moment, the alternatives are, what, using a dict to map values? trying to shoehorn a corrsponding set of values into an enum? using the existing switch statement (pretty verbose in Swift, due to "let" scope etc)? In my own Swift code, I have encountered situations, frequently, where I wished I had an equivalent to a ternary condition that handled more than two values. Chaining multiple ternary conditions together is unreadable. This proposed Switch assignment expression would take care of that.

Definitely has my vote!

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

[anandabits (Matthew Johnson)]

IMO, in order to consider removing ternary, we’d have to introduce something that is *better* than the current ternary operator first.

Do you have any thoughts about what might constitute *better* in your mind no matter how vague they might be? Mostly curious about this.

I always have to stop and think if I encounter a chained ternary expression but never do when I encounter chained if statements. Maybe that’s just because I encounter them pretty infrequently but IMO it seems to indicate that the search for something better is worthwhile.

Matthew

[masters3d]

Pick is interesting but how do you chain more that one pick/from together?

I thought about just just dropping the if.

let result = bool then 1 else bool then 2 else 3

Or going back to the python style.

let result = 1 where bool else where bool 2 else 3

But you are right, can't beat just having two characters. Specially when
the Elvis operator is in every other major c based language.

Perhaps this is just a like ! as a negation character, once you learn the
differences then u are set for other languages as well.

It would be nice to be able to bind expressions so that the actual logic of
the ?: is not lost.

let result = if (long_boolexpresion,
                   longerBoolexoression,
                   anotherboolExpression )
                   $0 then "a" else $1 && $2 then "b" else "c"

···

On Tuesday, December 15, 2015, Paul Ossenbruggen via swift-evolution < swift-evolution@swift.org> wrote:

I think pick…from may address many of the negatives listed by Chris. with
the if..then..else approach.

The closest proposal I’ve seen is the “if cond then value1 else value2”
syntax, however that has serious (IMO) problems:

- It is substantially more verbose than ?:, so much so that it obscures
the logic that was trying to be captured. Simple things like this become
swallowed in syntax:
  let x = cond ? 4 : 8
  let x = if cond then 4 else 8

this suggestion would still be longer, you can’t beat 2 chars. It is
shorter than if..then..else though. Not sure there are any good options
that can beat the conciseness of the ternary without replacing it with more
syntax.

let x = pick cond from 4, 8

- Because it looks like an if statement, people will end up writing it
like:

let x = if cond then
some_long_expression
   else
some_other_long_expression

- it only accepts expressions, not statements. The way it is flowed
makes it look like a statement.
- It is now force indenting a lot, which just looks weird and isn’t
precedented in Swift.

By having a new keyword, we can define the format and there is no prior
connotation with it.

When this happens, we now have new problems:
- At a glance, it “looks” like an if statement, but it is semantically
different.

Since it is a new it will always look like something that handles
expressions only.

Also this pick…from statement can be extended to handle switch expressions
as well. So it is consistent way to do different expressions based upon an
input.

Some downsides:
new keyword
no prior history with other programming languages.

On Dec 15, 2015, at 4:31 PM, Paul Ossenbruggen <possen@gmail.com > <javascript:_e(%7B%7D,'cvml','possen@gmail.com');>> wrote:

Been thinking a bit:

Perhaps a new expression is in order. “Pick” this has a form like this.
Param is a selector This only allows expressions

It has two forms:

To replace ternary:

let x = pick val from "abc", "cdef"

To replace switch expressions. The cases follows existing rules for switch
cases.

let y = pick val from cases .Red: 1, .Green: 2, .Blue: 3

This keeps the notion of expressions and statements quite separate. It
avoids syntax confusion. It reads clear. It is fairy concise. It uses a
straight forward pattern for both forms of expression.

- Paul

On Dec 15, 2015, at 2:06 PM, Charles Constant via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

+1 bigtime for the assignment via Switch proposal

I think someone here made the argument, I can't remember who, that it
would be confusing for beginners. I think exactly the opposite.

Once a new programmer has learned how to write a normal Switch statement,
they'll be able to "leverage" the same concept and map values using the
Switch assignment. Some might even try it on their on own, through
experimentation, to see if it will work. It's such a pleasant experience
when you try something in a language that seems consistent with what you
already know, and discover "cool, it works!"

At the moment, the alternatives are, what, using a dict to map values?
trying to shoehorn a corrsponding set of values into an enum? using the
existing switch statement (pretty verbose in Swift, due to "let" scope
etc)? In my own Swift code, I have encountered situations, frequently,
where I wished I had an equivalent to a ternary condition that handled more
than two values. Chaining multiple ternary conditions together is
unreadable. This proposed Switch assignment expression would take care of
that.

Definitely has my vote!

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner1 (Chris Lattner)]

No, I’m not aware of anything that I’d consider to be better than ?:

In brief, and just MHO, but:

- I agree that ?: is ugly and magic, and is an additional thing people have to learn if coming to swift without encountering a C family language.
- I agree that it is unfortunate that it uses “?” in particular, since we’d prefer that to be associated with optionals.

The closest proposal I’ve seen is the “if cond then value1 else value2” syntax, however that has serious (IMO) problems:
- It is substantially more verbose than ?:, so much so that it obscures the logic that was trying to be captured. Simple things like this become swallowed in syntax:
   let x = cond ? 4 : 8
   let x = if cond then 4 else 8

- Because it looks like an if statement, people will end up writing it like:

let x = if cond then
    some_long_expression
     else
    some_other_long_expression

When this happens, we now have new problems:
  - At a glance, it “looks” like an if statement, but it is semantically different.
  - it only accepts expressions, not statements. The way it is flowed makes it look like a statement.
  - It is now force indenting a lot, which just looks weird and isn’t precedented in Swift.

On this thread, people have been focusing on the negative parts of ?: without considering the positive aspects of it. Here are some of the positive aspects of it:

- It is extremely concise, and covers a very common pattern.
- It is pervasively standardized in a very wide range of languages.
- It’s weird syntax reduces the odds that people would flow it out and use very large expressions in it.
- It chains well for multiple conditions because of its associativity.

To repeat what I said upthread, to build a compelling case that we should replace ?:, its replacement should be *better* than ?:.

Believe it or not, we only change things when there are strong reasons, and in the absence of any other strong reason, being similar to the C family is a benefit, not a problem.

-Chris

···

On Dec 15, 2015, at 1:44 PM, Matthew Johnson <matthew@anandabits.com> wrote:

IMO, in order to consider removing ternary, we’d have to introduce something that is *better* than the current ternary operator first.

Do you have any thoughts about what might constitute *better* in your mind no matter how vague they might be? Mostly curious about this.

[possen (Paul Ossenbruggen)]

Selector Operator Proposal

OK really trying to get this down to its essence, make something that is truly better and more powerful than ternary, and try to keep as much of the advantages of the ternary and hopefully slightly improve the readability. I am calling it the "selector operator". This proposal, does not add a new keyword but adds a new operator. It unifies the concepts of ternary and gives us a new switch like behavior that ternary does not support. The concept is kind of like a train track, with multiple possible directions selectable by one input.

I believe it also addresses the issues that Chris mentioned.

to select from a boolean, a or b:
let a = sel ->> true, false

to select from an enum values as in a switch:

let a = sel ->> .Red: 1, .Green: 2, .Blue: 3
let b = sel ->> .Red: 1, .Green: 2, .Blue: 3, default: 4
let c = sel ->> case .Red: 1, case .Green: 2, case .Blue: 3, default: 4
let d = sel ->> .Red: 1, (sel ->> .Sun: .Yellow, .Moon: .White, .Stars: .Twinkle), .Green: 2, .Blue: 3, default: 4
let e = sel ->> cases: .Red: 1, case .Green: 2, case .Blue: 3, default: 4

a) shows all possible routes handled.
b) shows a default form
c) shows form with case (follows existing switch rules so should be familiar)
d) shows nested form.
e) shows a slight modification to cases label to balance the default, I think balance can be helpful. User can choose concise vs balance.

to select from an integer or any other enumerable type:

let f = sel ->> “A", “B", “C", “D”. “E”, “F”, default: “G”
let g = sel ->> cases: “A", “B", “C", “D”. “E”, “F”, default: “G”

e) shows compact form, must have default because all integers would make for a long list.
f) shows a slight modification to cases label to balance the default, I think balance can be helpful. User can choose concise vs balance.

Advantages:
• This lets ? operator be used only for optionals.
• It pops out in code similar to the ternary operator.
• Slightly improved readability
• Unifies the switch and ternary concepts.
• No new keyword (well, cases: is a minor addition)
• new operator allows us to define how it should be formatted as there is no preconceived notion of how it should be formatted
• By definition it only deals in expressions.
• There is no way it can be confused with statements.
• the interesting syntax would keep people from doing very large expressions in it (Paraphrasing Chris)
• chains well for multiple conditions because of its associativity
• because it is a new concept there is potential to extend it in the future.

Disadvantages:
• May be a slight improvement in readability. Operators have to be looked up if you are not familiar with them.
• New concept that will have to be learned and not present in most C like languages so needs to be learned.

Other Half Baked thoughts:
• Are there other data types that would work with this? Maybe Objects, Dictionaries, Arrays, Ranges enumerations, or Structs (Unions?)
* What would container types look like? Could you call it multiple times on an array? Kind of like a map like behavior where each element goes into the selector operator.

- Paul

···

On Dec 16, 2015, at 8:04 AM, J. Cheyo Jimenez <cheyo@masters3d.com> wrote:

Pick is interesting but how do you chain more that one pick/from together?

I thought about just just dropping the if.

let result = bool then 1 else bool then 2 else 3

Or going back to the python style.

let result = 1 where bool else where bool 2 else 3

But you are right, can't beat just having two characters. Specially when the Elvis operator is in every other major c based language.

Perhaps this is just a like ! as a negation character, once you learn the differences then u are set for other languages as well.

It would be nice to be able to bind expressions so that the actual logic of the ?: is not lost.

let result = if (long_boolexpresion,
                   longerBoolexoression,
                   anotherboolExpression )
                   $0 then "a" else $1 && $2 then "b" else "c"

On Tuesday, December 15, 2015, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I think pick…from may address many of the negatives listed by Chris. with the if..then..else approach.

The closest proposal I’ve seen is the “if cond then value1 else value2” syntax, however that has serious (IMO) problems:

- It is substantially more verbose than ?:, so much so that it obscures the logic that was trying to be captured. Simple things like this become swallowed in syntax:
  let x = cond ? 4 : 8
  let x = if cond then 4 else 8

this suggestion would still be longer, you can’t beat 2 chars. It is shorter than if..then..else though. Not sure there are any good options that can beat the conciseness of the ternary without replacing it with more syntax.

let x = pick cond from 4, 8

- Because it looks like an if statement, people will end up writing it like:

let x = if cond then
    some_long_expression
     else
    some_other_long_expression

- it only accepts expressions, not statements. The way it is flowed makes it look like a statement.
- It is now force indenting a lot, which just looks weird and isn’t precedented in Swift.

By having a new keyword, we can define the format and there is no prior connotation with it.

When this happens, we now have new problems:
- At a glance, it “looks” like an if statement, but it is semantically different.

Since it is a new it will always look like something that handles expressions only.

Also this pick…from statement can be extended to handle switch expressions as well. So it is consistent way to do different expressions based upon an input.

Some downsides:
new keyword
no prior history with other programming languages.

On Dec 15, 2015, at 4:31 PM, Paul Ossenbruggen <possen@gmail.com <javascript:_e(%7B%7D,'cvml','possen@gmail.com');>> wrote:

Been thinking a bit:

Perhaps a new expression is in order. “Pick” this has a form like this. Param is a selector This only allows expressions

It has two forms:

To replace ternary:

let x = pick val from "abc", "cdef"

To replace switch expressions. The cases follows existing rules for switch cases.

let y = pick val from cases .Red: 1, .Green: 2, .Blue: 3

This keeps the notion of expressions and statements quite separate. It avoids syntax confusion. It reads clear. It is fairy concise. It uses a straight forward pattern for both forms of expression.

- Paul

On Dec 15, 2015, at 2:06 PM, Charles Constant via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

+1 bigtime for the assignment via Switch proposal

I think someone here made the argument, I can't remember who, that it would be confusing for beginners. I think exactly the opposite.

Once a new programmer has learned how to write a normal Switch statement, they'll be able to "leverage" the same concept and map values using the Switch assignment. Some might even try it on their on own, through experimentation, to see if it will work. It's such a pleasant experience when you try something in a language that seems consistent with what you already know, and discover "cool, it works!"

At the moment, the alternatives are, what, using a dict to map values? trying to shoehorn a corrsponding set of values into an enum? using the existing switch statement (pretty verbose in Swift, due to "let" scope etc)? In my own Swift code, I have encountered situations, frequently, where I wished I had an equivalent to a ternary condition that handled more than two values. Chaining multiple ternary conditions together is unreadable. This proposed Switch assignment expression would take care of that.

Definitely has my vote!

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner1 (Chris Lattner)]

I’m not sure how I feel about this proposal in general, but if you changed the RHS to take a tuple, you could define it entirely in the library as a binary operator, instead of hacking it into the compiler, like ?: is.

  let a = sel ->> (true, false)

The primary disadvantage of this (which is probably a showstopper!) is that you lose short circuiting.

-Chris

···

On Dec 16, 2015, at 2:56 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

Selector Operator Proposal

OK really trying to get this down to its essence, make something that is truly better and more powerful than ternary, and try to keep as much of the advantages of the ternary and hopefully slightly improve the readability. I am calling it the "selector operator". This proposal, does not add a new keyword but adds a new operator. It unifies the concepts of ternary and gives us a new switch like behavior that ternary does not support. The concept is kind of like a train track, with multiple possible directions selectable by one input.

I believe it also addresses the issues that Chris mentioned.

to select from a boolean, a or b:
let a = sel ->> true, false

[Chris_Lattner1 (Chris Lattner)]

This specific proposal has another problem. Since you’re using “,” you’ve introduced grammar problems. For example, you wouldn’t be able to use this operator in a function argument list or array literal, because the , would be parsed as part of the argument list separator.

-Chris

···

On Dec 16, 2015, at 2:56 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

I believe it also addresses the issues that Chris mentioned.

to select from a boolean, a or b:
let a = sel ->> true, false

to select from an enum values as in a switch:

let a = sel ->> .Red: 1, .Green: 2, .Blue: 3
let b = sel ->> .Red: 1, .Green: 2, .Blue: 3, default: 4
let c = sel ->> case .Red: 1, case .Green: 2, case .Blue: 3, default: 4
let d = sel ->> .Red: 1, (sel ->> .Sun: .Yellow, .Moon: .White, .Stars: .Twinkle), .Green: 2, .Blue: 3, default: 4
let e = sel ->> cases: .Red: 1, case .Green: 2, case .Blue: 3, default: 4

Disadvantages:
• May be a slight improvement in readability. Operators have to be looked up if you are not familiar with them.
• New concept that will have to be learned and not present in most C like languages so needs to be learned.

[possen (Paul Ossenbruggen)]

Hi Chris,

So, just trying to understand if you think this is a good direction to continue with or you think it is inherently flawed.

Can you give me an example of a function argument list or array separator that we would have a problem? I will see if I can address it.

Thanks for the feedback!

- Paul

···

On Dec 16, 2015, at 3:14 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 16, 2015, at 2:56 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I believe it also addresses the issues that Chris mentioned.

to select from a boolean, a or b:
let a = sel ->> true, false

to select from an enum values as in a switch:

let a = sel ->> .Red: 1, .Green: 2, .Blue: 3
let b = sel ->> .Red: 1, .Green: 2, .Blue: 3, default: 4
let c = sel ->> case .Red: 1, case .Green: 2, case .Blue: 3, default: 4
let d = sel ->> .Red: 1, (sel ->> .Sun: .Yellow, .Moon: .White, .Stars: .Twinkle), .Green: 2, .Blue: 3, default: 4
let e = sel ->> cases: .Red: 1, case .Green: 2, case .Blue: 3, default: 4

Disadvantages:
• May be a slight improvement in readability. Operators have to be looked up if you are not familiar with them.
• New concept that will have to be learned and not present in most C like languages so needs to be learned.

This specific proposal has another problem. Since you’re using “,” you’ve introduced grammar problems. For example, you wouldn’t be able to use this operator in a function argument list or array literal, because the , would be parsed as part of the argument list separator.

-Chris

[possen (Paul Ossenbruggen)]

So maybe just eliminating the commas is enough, if possible I would like to avoid using parenthesis. I am not sure the rules, could do something like this

if possible would prefer not adding parens if possible (this is cleaner than the original proposal):

let a = sel ->> .Red: 1 .Green: 2 .Blue: 3

if it is necessary then something like this:

let a = (sel ->> .Red: 1, .Green: 2, .Blue: 3)

or

let a = (sel ->> .Red: 1 .Green: 2 .Blue: 3)

or

let a = sel ->(.Red: 1, .Green: 2, .Blue: 3)

So essentially it is a multiplexer.

- Paul

···

On Dec 16, 2015, at 4:36 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

Hi Chris,

So, just trying to understand if you think this is a good direction to continue with or you think it is inherently flawed.

Can you give me an example of a function argument list or array separator that we would have a problem? I will see if I can address it.

Thanks for the feedback!

- Paul

On Dec 16, 2015, at 3:14 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Dec 16, 2015, at 2:56 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I believe it also addresses the issues that Chris mentioned.

to select from a boolean, a or b:
let a = sel ->> true, false

to select from an enum values as in a switch:

let a = sel ->> .Red: 1, .Green: 2, .Blue: 3
let b = sel ->> .Red: 1, .Green: 2, .Blue: 3, default: 4
let c = sel ->> case .Red: 1, case .Green: 2, case .Blue: 3, default: 4
let d = sel ->> .Red: 1, (sel ->> .Sun: .Yellow, .Moon: .White, .Stars: .Twinkle), .Green: 2, .Blue: 3, default: 4
let e = sel ->> cases: .Red: 1, case .Green: 2, case .Blue: 3, default: 4

Disadvantages:
• May be a slight improvement in readability. Operators have to be looked up if you are not familiar with them.
• New concept that will have to be learned and not present in most C like languages so needs to be learned.

This specific proposal has another problem. Since you’re using “,” you’ve introduced grammar problems. For example, you wouldn’t be able to use this operator in a function argument list or array literal, because the , would be parsed as part of the argument list separator.

-Chris

[Chris_Lattner1 (Chris Lattner)]

Hi Chris,

So, just trying to understand if you think this is a good direction to continue with or you think it is inherently flawed.

Can you give me an example of a function argument list or array separator that we would have a problem? I will see if I can address it.

Transform this into your proposed syntax.
func foo(a : Int, b : Float) {}
foo(true ? 1 : 2, 3)

-Chris

···

On Dec 16, 2015, at 4:36 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

Thanks for the feedback!

- Paul

On Dec 16, 2015, at 3:14 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Dec 16, 2015, at 2:56 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I believe it also addresses the issues that Chris mentioned.

to select from a boolean, a or b:
let a = sel ->> true, false

to select from an enum values as in a switch:

let a = sel ->> .Red: 1, .Green: 2, .Blue: 3
let b = sel ->> .Red: 1, .Green: 2, .Blue: 3, default: 4
let c = sel ->> case .Red: 1, case .Green: 2, case .Blue: 3, default: 4
let d = sel ->> .Red: 1, (sel ->> .Sun: .Yellow, .Moon: .White, .Stars: .Twinkle), .Green: 2, .Blue: 3, default: 4
let e = sel ->> cases: .Red: 1, case .Green: 2, case .Blue: 3, default: 4

Disadvantages:
• May be a slight improvement in readability. Operators have to be looked up if you are not familiar with them.
• New concept that will have to be learned and not present in most C like languages so needs to be learned.

This specific proposal has another problem. Since you’re using “,” you’ve introduced grammar problems. For example, you wouldn’t be able to use this operator in a function argument list or array literal, because the , would be parsed as part of the argument list separator.

-Chris

[Charles_Constant]

I think I still prefer the original proposal to add a second syntax for
"switch" because it requires no learning curve at all. Even if I spent a
year without coding a single line of Swift, I'm sure when I came back to it
I'd remember the syntax for a "switch" assignment.

Having said that, I'd prefer sticking with a "?" since it's reminiscent of
a ternary, and regardless of parsing issues, it's easier to read if the
options are a tuple. So my second choice would be this variant of Paul's
suggestion:

    let a = sel ? (.Red: 1, .Green: 2, .Blue: 3)

[Charles_Constant]

One more thought. This syntax would also placate ternary haters. I think
the traditional complaint about ternary expressions is that people can't
remember the order of the true and false values. This would not be an issue
with:

let i = boo ? ( true: 123, false: 456 )

[Chris_Lattner1 (Chris Lattner)]

I would characterize this as “different” than ?:, but not better. Given that it isn’t “better”, I’d argue that following C (and tons of other languages) would make sense here.

-Chris

···

On Dec 16, 2015, at 7:36 PM, Charles Constant <charles@charlesism.com> wrote:

One more thought. This syntax would also placate ternary haters. I think the traditional complaint about ternary expressions is that people can't remember the order of the true and false values. This would not be an issue with:

let i = boo ? ( true: 123, false: 456 )

[Vester_Gottfried]

What do you think about this?

let i = if(x == y, 123, 456)

the second parameter could be optional, so if the condition is false you
would get a nil

let i = if(x == y, 123) // may return nil

making it function like would make a bit more natural to chain other
functions

let i = if(x == y, 123).map( ... )

I am usually not an opponent of the ternary conditional operator, but I do
know instances where beginner were struggling with it, when they first
encountered it. That you cannot google it makes it worse. And in Swift the
question mark has a special meaning regarding optionals, that other
languages don't have.

This is just an quick idea though. I agree with Chris, that we should only
replace it, when we are really sure the new solution is better.

···

On Thu, Dec 17, 2015 at 4:36 AM, Charles Constant via swift-evolution < swift-evolution@swift.org> wrote:

One more thought. This syntax would also placate ternary haters. I think
the traditional complaint about ternary expressions is that people can't
remember the order of the true and false values. This would not be an issue
with:

let i = boo ? ( true: 123, false: 456 )

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

[masters3d]

Thank you Chris for all the feedback.

Should there be a spot on the website or github with frequent
proposed changes that are not feasible or that not better solution has been
found (such as the ?: operator )?

I am thinking this would cut down on people asking to turn operators into
keywords (or similar ) but still encourage better solutions to be proposed.

···

On Wednesday, December 16, 2015, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

> On Dec 16, 2015, at 7:36 PM, Charles Constant <charles@charlesism.com > <javascript:;>> wrote:
>
> One more thought. This syntax would also placate ternary haters. I think
the traditional complaint about ternary expressions is that people can't
remember the order of the true and false values. This would not be an issue
with:
>
> let i = boo ? ( true: 123, false: 456 )

I would characterize this as “different” than ?:, but not better. Given
that it isn’t “better”, I’d argue that following C (and tons of other
languages) would make sense here.

-Chris

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

[Charles_Constant]

I've never hated the ternary operator, so I wouldn't feel comfortable
arguing very strongly against it. To my eyes, in situations where it's just
a choice of true/false, I agree the suggestions in this thread are not as
nice.

My reason for suggesting the change is that it would be nice to have a one
liner for non-boolean values. Especially when the mapping isn't likely to
be reused anyplace else. I run into this a fair amount, and the inline way
I do it (via a Dict) requires a lot of verbosity (keys are likely to be
Enums and need to be explicitly declared for the Dict). Either that or I
extend an Enum, but that's also verbose when I never intend to reuse the
mapping elsewhere in my project. So this would be handy:

Eg:

let str = dir ? (
    .Png: "Export Png",
    .Jpeg: "Export Jpeg",
    .Tiff: "Save (native)",
)

let i = boo ? (
    true: 1,
    false: 0,
    nil: -1
)

Uh hang on... I guess "nil" is invalid as a tuple key. But hey! Other than
that, the syntax would have been convenient :)

Anyways I've harped on this enough. I can live without it, if others aren't
keen on it.

​