ternary operator ?: suggestion

[Al_Skipp]

That’s a really interesting idea.
There’s potential to add parameter names. Ideally the second parameter name would be ‘else’, but that’s not really workable.

func when<T>(fn: Bool, @autoclosure then: () -> T, @autoclosure or: () -> T) -> T {
  if fn { return then() }
  return or()
}

let x = when(true, then: 0, or: 1)

Nested version might be a bit scary though ; )

let nested = when(false, then: 0, or: when(false, then: 2, or: when(true, then: 3, or: 4)))

Al

···

On 14 Dec 2015, at 18:38, David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

Thanks for the updated proposals; they are much easier to go through then the vast number of mails on this thread. I’ve tried to follow this thread as best as possible, so please forgive me if this has been addressed but I couldn’t find it.

Can you add to the proposal why a function cannot be added for tertiary expressions (under “Alternates Considered”):

func either<T>(@autoclosure fn: () -> Bool, @autoclosure _ left: () -> T, @autoclosure _ right: () -> T) -> T {
    if fn() { return left() }
    return right()
}

let x = true ? 0 : 1

let y = either(true, 0, 1)

let f1: () -> Int = { print("f1"); return 0 }
let f2: () -> Int = { print("f2"); return 2 }
let z = either(true, f1(), f2())

let nested = either(false, 0, either(false, 2, either(true, 3, 4)))

This isn’t a full replacement for if-statements as expressions, but doesn’t it satisfy the tertiary requirements, at least in the most common of cases? The fallback is to use if-else if side-effects are something that is desired?

The name for the function could be better, but the point is to remove it from the parsing structure all together. Or is that something you find valuable?

-David

[possen (Paul Ossenbruggen)]

Hi Chris,

Yes definitely, after splitting the proposal up, and some of the feedback I got on the first draft, I became less enamored of the idea and I understand the objections, and we need answer the question "is this really better?”. If others have strong reasons why they really don’t like ternary or reasons they may have heard, please let me know and I would be happy to add them to the proposal.

- Paul

···

On Dec 14, 2015, at 10:57 AM, Chris Lattner <clattner@apple.com> wrote:

On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Once again, thank you for all the feedback, if I sound in anyway grumpy in responding to any email, it has a bit more to do with my cold than the suggestions.

I have split the original proposal into two proposals and incorporated a bunch of feedback. Splitting it up has been extremely good, not only does it improve readability, I am actually finding I could take or leave the ternary replacement idea. But the proposal will be there if enough everyone thinks it is a good idea. We could put it to a vote to see if there is enough interest and I would be happy to take it further if there is. I suspect this thread would not exist at all if there was no interest in it. However, I am finding I am far more interested in getting switch expressions.

Ternary Replacement
https://github.com/possen/swift-evolution/blob/master/0021.md

Quick comment. The proposal states:

Is it really better? Why not just keep ternary expressions?
This is a valid question, there is an advantage in compactness to ternary expressions. I however frequently hear people saying ternary should be avoided because they are hard to read or they hate them. There seems to many who either stronly dislike it or don't care.

However, it doesn’t actually show that it is solving the objections people have to the ternary operator. It is true that some people find the ?: syntax weird, but an equal number of people say that the problem is that you’re putting complex conditional logic inline into the middle of an expression - this proposal actually makes that objection worse. There are also other objections to ?:, and until you enumerate them, it is hard to see whether this proposal is making things better or worse.

-Chris

[Andrey_Tarantsov]

Can you add to the proposal why a function cannot be added for tertiary expressions (under “Alternates Considered”):

That's one fresh idea, and I like it. I can't find anything wrong with it, except that fn doesn't need to be an @autoclosure, just a Bool.

I believe the customary name for that function is iff.

I always wrap ?: in parenthesis for readability anyway.

A.

[Austin (Austin Zheng)]

I am strongly against this proposal.

In terms of clarity: Paul Cantrill made the very good point in a different
thread that "beginner-friendly" syntax may not be the same as syntax
optimized for the productivity of developers working on serious projects. I
think this is a great example of that principle in action. Sigils stand out
to the eye when scanning code in a way that keywords don't, even in an IDE
with syntax highlighting (and the perils of relying upon relying upon color
have been discussed pretty thoroughly in the mandatory 'self' thread).
Replacing them with keywords makes it harder to delineate the arguments.

In terms of semantics: The argument was made earlier that "?" is associated
closely with optionals and not suitable for this purpose; I disagree: "?"'s
overarching meaning is that of uncertainty or querying, which makes sense
both in terms of control flow (predicate determines which way to go), as
well as optionals (whose 'empty or not' status is unknown until explicitly
checked for, e.g. via if-let).

In terms of beginner-friendliness: I don't think the ternary symbols are
particularly difficult to learn. The operators show up in other languages
as well and the actual usage rules are very simple. On the other hand, I
don't think having two related-but-distinct forms of if-else, or mangling
multi-line if-else into a form quite dissimilar to those of other languages
(or of the other control flow constructs in Swift) is helpful to people
learning the language.

My personal preference is to hold a separate discussion as to whether or
not we should have expression variants of the if, switch, and other control
flow statements, but even so I don't see them as a replacement for
single-line expressions using the ternary operator being discussed.

Best,
Austin

···

On Mon, Dec 14, 2015 at 4:50 PM, Nick Shelley via swift-evolution < swift-evolution@swift.org> wrote:

I however frequently hear people saying ternary should be avoided because

they are hard to read or they hate them.

FWIW, I used to be one of those people, but then started working on a team
where one member liked them. He didn't force them on us, but after enough
code reviews where he showed us how to turn 5-line if/else statements into
simple one-line ternary expressions, I got used to reading them and now
love them and use them often.

People also hate map, flatMap, reduce, etc., for the same reasons (it's
hard for them to read because it's not the for loop they're used to). I
think it's a simple matter of getting used to it.

On Mon, Dec 14, 2015 at 11:57 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution < >> swift-evolution@swift.org> wrote:

Once again, thank you for all the feedback, if I sound in anyway grumpy
in responding to any email, it has a bit more to do with my cold than the
suggestions.

I have split the original proposal into two proposals and incorporated a
bunch of feedback. Splitting it up has been extremely good, not only does
it improve readability, I am actually finding I could take or leave the
ternary replacement idea. But the proposal will be there if enough everyone
thinks it is a good idea. We could put it to a vote to see if there is
enough interest and I would be happy to take it further if there is. I
suspect this thread would not exist at all if there was no interest in it.
However, I am finding I am far more interested in getting switch
expressions.

Ternary Replacement
https://github.com/possen/swift-evolution/blob/master/0021.md

Quick comment. The proposal states:

Is it really better? Why not just keep ternary expressions?
This is a valid question, there is an advantage in compactness to ternary
expressions. I however frequently hear people saying ternary should be
avoided because they are hard to read or they hate them. There seems to
many who either stronly dislike it or don't care.

However, it doesn’t actually show that it is solving the objections
people have to the ternary operator. It is true that some people find the
?: syntax weird, but an equal number of people say that the problem is that
you’re putting complex conditional logic inline into the middle of an
expression - this proposal actually makes that objection worse. There are
also other objections to ?:, and until you enumerate them, it is hard to
see whether this proposal is making things better or worse.

-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

[possen (Paul Ossenbruggen)]

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

Is this new syntax helping?

    return if a < b
  then if b < c
    then b
          else if a < c
       then c
       else a
  else if a < c
    then a
    else if b < c
             then c
       else b

I found this translation quite tricky to do. maybe parens help?

    return (if a < b
  then (if b < c
    then b
          else (if a < c
       then c
       else a))
  else (if a < c
    then a
    else (if b < c
             then c
       else b)))

Not really and I still I found this hugely frustrating, so much so that I am going to drop all support for this proposal and remove my name from it. If anyone wants to take over feel free.

Others still keen on the idea should try this experiment. It convinced me is horrible idea :-) I don’t want to be blamed for it by every Swift programmer in the future.

I do still however like the Swift Expressions.

- Paul

···

On Dec 14, 2015, at 4:50 PM, Nick Shelley via swift-evolution <swift-evolution@swift.org> wrote:

I however frequently hear people saying ternary should be avoided because they are hard to read or they hate them.

FWIW, I used to be one of those people, but then started working on a team where one member liked them. He didn't force them on us, but after enough code reviews where he showed us how to turn 5-line if/else statements into simple one-line ternary expressions, I got used to reading them and now love them and use them often.

People also hate map, flatMap, reduce, etc., for the same reasons (it's hard for them to read because it's not the for loop they're used to). I think it's a simple matter of getting used to it.

On Mon, Dec 14, 2015 at 11:57 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Once again, thank you for all the feedback, if I sound in anyway grumpy in responding to any email, it has a bit more to do with my cold than the suggestions.

I have split the original proposal into two proposals and incorporated a bunch of feedback. Splitting it up has been extremely good, not only does it improve readability, I am actually finding I could take or leave the ternary replacement idea. But the proposal will be there if enough everyone thinks it is a good idea. We could put it to a vote to see if there is enough interest and I would be happy to take it further if there is. I suspect this thread would not exist at all if there was no interest in it. However, I am finding I am far more interested in getting switch expressions.

Ternary Replacement
https://github.com/possen/swift-evolution/blob/master/0021.md

Quick comment. The proposal states:

Is it really better? Why not just keep ternary expressions?
This is a valid question, there is an advantage in compactness to ternary expressions. I however frequently hear people saying ternary should be avoided because they are hard to read or they hate them. There seems to many who either stronly dislike it or don't care.

However, it doesn’t actually show that it is solving the objections people have to the ternary operator. It is true that some people find the ?: syntax weird, but an equal number of people say that the problem is that you’re putting complex conditional logic inline into the middle of an expression - this proposal actually makes that objection worse. There are also other objections to ?:, and until you enumerate them, it is hard to see whether this proposal is making things better or worse.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

[Craig_Cruden]

I would actually prefer the if statement become more functional vs flow-control which would encompass the ternary statement.

So

let x = if (boolean) “true” else “false”

or

let x =
  if (boolean)
    “true”
  else
    “false”

or

let n =
  if (boolean) {
    print(“test”)
    “true”
  }
  else
    false

If becomes just another function as opposed to pure flow-control.

A similar approach to switch would also be nice.

Before Swift was really just a vehicle for UI applications, but now it is aiming to be more of a general language for server as well (available on Linux). UI’s generally by their nature are object-oriented, and thus extending it’s functional side was not a priority….. but moving forward it would be nice if it incorporated more of Scala’s functional paradigm into the language (where it does not overtly affect performance) so that developers can program functionally or object-oriented - whatever is the best fit.

-Craig

···

On 2015-12-15, at 12:01:46, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

Hi Chris,

Yes definitely, after splitting the proposal up, and some of the feedback I got on the first draft, I became less enamored of the idea and I understand the objections, and we need answer the question "is this really better?”. If others have strong reasons why they really don’t like ternary or reasons they may have heard, please let me know and I would be happy to add them to the proposal.

- Paul

On Dec 14, 2015, at 10:57 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Once again, thank you for all the feedback, if I sound in anyway grumpy in responding to any email, it has a bit more to do with my cold than the suggestions.

I have split the original proposal into two proposals and incorporated a bunch of feedback. Splitting it up has been extremely good, not only does it improve readability, I am actually finding I could take or leave the ternary replacement idea. But the proposal will be there if enough everyone thinks it is a good idea. We could put it to a vote to see if there is enough interest and I would be happy to take it further if there is. I suspect this thread would not exist at all if there was no interest in it. However, I am finding I am far more interested in getting switch expressions.

Ternary Replacement
https://github.com/possen/swift-evolution/blob/master/0021.md

Quick comment. The proposal states:

Is it really better? Why not just keep ternary expressions?
This is a valid question, there is an advantage in compactness to ternary expressions. I however frequently hear people saying ternary should be avoided because they are hard to read or they hate them. There seems to many who either stronly dislike it or don't care.

However, it doesn’t actually show that it is solving the objections people have to the ternary operator. It is true that some people find the ?: syntax weird, but an equal number of people say that the problem is that you’re putting complex conditional logic inline into the middle of an expression - this proposal actually makes that objection worse. There are also other objections to ?:, and until you enumerate them, it is hard to see whether this proposal is making things better or worse.

-Chris

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

[possen (Paul Ossenbruggen)]

I should have said “Switch Expressions” not “Swift Expression”

···

On Dec 14, 2015, at 10:41 PM, Paul Ossenbruggen <possen@gmail.com> 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

Is this new syntax helping?

    return if a < b
  then if b < c
    then b
          else if a < c
       then c
       else a
  else if a < c
    then a
    else if b < c
             then c
       else b

I found this translation quite tricky to do. maybe parens help?

    return (if a < b
  then (if b < c
    then b
          else (if a < c
       then c
       else a))
  else (if a < c
    then a
    else (if b < c
             then c
       else b)))

Not really and I still I found this hugely frustrating, so much so that I am going to drop all support for this proposal and remove my name from it. If anyone wants to take over feel free.

Others still keen on the idea should try this experiment. It convinced me is horrible idea :-) I don’t want to be blamed for it by every Swift programmer in the future.

I do still however like the Swift Expressions.

- Paul

On Dec 14, 2015, at 4:50 PM, Nick Shelley via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I however frequently hear people saying ternary should be avoided because they are hard to read or they hate them.

FWIW, I used to be one of those people, but then started working on a team where one member liked them. He didn't force them on us, but after enough code reviews where he showed us how to turn 5-line if/else statements into simple one-line ternary expressions, I got used to reading them and now love them and use them often.

People also hate map, flatMap, reduce, etc., for the same reasons (it's hard for them to read because it's not the for loop they're used to). I think it's a simple matter of getting used to it.

On Mon, Dec 14, 2015 at 11:57 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Once again, thank you for all the feedback, if I sound in anyway grumpy in responding to any email, it has a bit more to do with my cold than the suggestions.

I have split the original proposal into two proposals and incorporated a bunch of feedback. Splitting it up has been extremely good, not only does it improve readability, I am actually finding I could take or leave the ternary replacement idea. But the proposal will be there if enough everyone thinks it is a good idea. We could put it to a vote to see if there is enough interest and I would be happy to take it further if there is. I suspect this thread would not exist at all if there was no interest in it. However, I am finding I am far more interested in getting switch expressions.

Ternary Replacement
https://github.com/possen/swift-evolution/blob/master/0021.md

Quick comment. The proposal states:

Is it really better? Why not just keep ternary expressions?
This is a valid question, there is an advantage in compactness to ternary expressions. I however frequently hear people saying ternary should be avoided because they are hard to read or they hate them. There seems to many who either stronly dislike it or don't care.

However, it doesn’t actually show that it is solving the objections people have to the ternary operator. It is true that some people find the ?: syntax weird, but an equal number of people say that the problem is that you’re putting complex conditional logic inline into the middle of an expression - this proposal actually makes that objection worse. There are also other objections to ?:, and until you enumerate them, it is hard to see whether this proposal is making things better or worse.

-Chris

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

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

[possen (Paul Ossenbruggen)]

I am strongly against this proposal.

In terms of clarity: Paul Cantrill made the very good point in a different thread that "beginner-friendly" syntax may not be the same as syntax optimized for the productivity of developers working on serious projects. I think this is a great example of that principle in action. Sigils stand out to the eye when scanning code in a way that keywords don't, even in an IDE with syntax highlighting (and the perils of relying upon relying upon color have been discussed pretty thoroughly in the mandatory 'self' thread). Replacing them with keywords makes it harder to delineate the arguments.

I agree they definitely stand out compared to keywords. also the nil-coelsincg operator when taken with the ternary operator, which seems to me, a spiritual brother, to it may seem even more alien.

In terms of semantics: The argument was made earlier that "?" is associated closely with optionals and not suitable for this purpose; I disagree: "?"'s overarching meaning is that of uncertainty or querying, which makes sense both in terms of control flow (predicate determines which way to go), as well as optionals (whose 'empty or not' status is unknown until explicitly checked for, e.g. via if-let).

Again when looking at the nil-coalescing operator, implicit unwrapping (!) and optional chaining, I agree. It seems that the ternary operator fits quite nicely with ? meaning this is a question and that notion is encoded repeated thorough the Swift language. ? is almost a key concept in the language and making it keywords takes away from that and it seems even more wise to keep as is because it was a good design from the start. I also see why Chris and others haven’t really wanted to get into this discussion, but wisely let it happen so we could come to the same conclusion. It is almost as if ? and ! are the core concepts of the language for new Swift learners.

In terms of beginner-friendliness: I don't think the ternary symbols are particularly difficult to learn. The operators show up in other languages as well and the actual usage rules are very simple. On the other hand, I don't think having two related-but-distinct forms of if-else, or mangling multi-line if-else into a form quite dissimilar to those of other languages (or of the other control flow constructs in Swift) is helpful to people learning the language.

Here I am arguing strongly against my own proposal because I do actually think it might make things worse than better :-) I think there is some value in the process of coming up with the proposal because it spells out what such a feature would/could look like. I suspect that this idea will keep coming up over the years on this list. Is there a way we can setup a FAQ, so that we can show this line of reasoning to newcomers to the list and make sure they are addressing these concerns if they are coming up with new ideas, or do people think that stifles the free flow of new ideas?

My personal preference is to hold a separate discussion as to whether or not we should have expression variants of the if, switch, and other control flow statements, but even so I don't see them as a replacement for single-line expressions using the ternary operator being discussed.

+1

···

On Dec 14, 2015, at 10:22 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

Best,
Austin

On Mon, Dec 14, 2015 at 4:50 PM, Nick Shelley via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I however frequently hear people saying ternary should be avoided because they are hard to read or they hate them.

FWIW, I used to be one of those people, but then started working on a team where one member liked them. He didn't force them on us, but after enough code reviews where he showed us how to turn 5-line if/else statements into simple one-line ternary expressions, I got used to reading them and now love them and use them often.

People also hate map, flatMap, reduce, etc., for the same reasons (it's hard for them to read because it's not the for loop they're used to). I think it's a simple matter of getting used to it.

On Mon, Dec 14, 2015 at 11:57 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Once again, thank you for all the feedback, if I sound in anyway grumpy in responding to any email, it has a bit more to do with my cold than the suggestions.

I have split the original proposal into two proposals and incorporated a bunch of feedback. Splitting it up has been extremely good, not only does it improve readability, I am actually finding I could take or leave the ternary replacement idea. But the proposal will be there if enough everyone thinks it is a good idea. We could put it to a vote to see if there is enough interest and I would be happy to take it further if there is. I suspect this thread would not exist at all if there was no interest in it. However, I am finding I am far more interested in getting switch expressions.

Ternary Replacement
https://github.com/possen/swift-evolution/blob/master/0021.md

Quick comment. The proposal states:

Is it really better? Why not just keep ternary expressions?
This is a valid question, there is an advantage in compactness to ternary expressions. I however frequently hear people saying ternary should be avoided because they are hard to read or they hate them. There seems to many who either stronly dislike it or don't care.

However, it doesn’t actually show that it is solving the objections people have to the ternary operator. It is true that some people find the ?: syntax weird, but an equal number of people say that the problem is that you’re putting complex conditional logic inline into the middle of an expression - this proposal actually makes that objection worse. There are also other objections to ?:, and until you enumerate them, it is hard to see whether this proposal is making things better or worse.

-Chris

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

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

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

[J_Cheyo_Jimenez]

Thank you Paul for the initial draft.

Here is the a draft version that I intend to submit.

masters3d/swift-evolution/blob/ReplaceTernary/proposals/00-Replace ?: Ternary Operator with if-then-else expression.md

···

On Monday, December 14, 2015, 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

Is this new syntax helping?

return if a < b
then if b < c
then b
else if a < c
then c
else a
else if a < c
then a
else if b < c
then c
else b

I found this translation quite tricky to do. maybe parens help?

return (if a < b
then (if b < c
then b
else (if a < c
then c
else a))
else (if a < c
then a
else (if b < c
then c
else b)))

Not really and I still I found this hugely frustrating, so much so that I
am going to drop all support for this proposal and remove my name from it.
If anyone wants to take over feel free.

Others still keen on the idea should try this experiment. It convinced me
is horrible idea :-) I don’t want to be blamed for it by every Swift
programmer in the future.

I do still however like the Swift Expressions.

- Paul

On Dec 14, 2015, at 4:50 PM, Nick Shelley via swift-evolution < > swift-evolution@swift.org> wrote:

I however frequently hear people saying ternary should be avoided because

they are hard to read or they hate them.

FWIW, I used to be one of those people, but then started working on a team
where one member liked them. He didn't force them on us, but after enough
code reviews where he showed us how to turn 5-line if/else statements into
simple one-line ternary expressions, I got used to reading them and now
love them and use them often.

People also hate map, flatMap, reduce, etc., for the same reasons (it's
hard for them to read because it's not the for loop they're used to). I
think it's a simple matter of getting used to it.

On Mon, Dec 14, 2015 at 11:57 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution < >> swift-evolution@swift.org> wrote:

Once again, thank you for all the feedback, if I sound in anyway grumpy
in responding to any email, it has a bit more to do with my cold than the
suggestions.

I have split the original proposal into two proposals and incorporated a
bunch of feedback. Splitting it up has been extremely good, not only does
it improve readability, I am actually finding I could take or leave the
ternary replacement idea. But the proposal will be there if enough everyone
thinks it is a good idea. We could put it to a vote to see if there is
enough interest and I would be happy to take it further if there is. I
suspect this thread would not exist at all if there was no interest in it.
However, I am finding I am far more interested in getting switch
expressions.

Ternary Replacement
https://github.com/possen/swift-evolution/blob/master/0021.md

Quick comment. The proposal states:

Is it really better? Why not just keep ternary expressions?
This is a valid question, there is an advantage in compactness to ternary
expressions. I however frequently hear people saying ternary should be
avoided because they are hard to read or they hate them. There seems to
many who either stronly dislike it or don't care.

However, it doesn’t actually show that it is solving the objections
people have to the ternary operator. It is true that some people find the
?: syntax weird, but an equal number of people say that the problem is that
you’re putting complex conditional logic inline into the middle of an
expression - this proposal actually makes that objection worse. There are
also other objections to ?:, and until you enumerate them, it is hard to
see whether this proposal is making things better or worse.

-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

[masters3d]

Thank you Paul for the initial draft.

Here is the a draft version that I intend to submit.

masters3d/swift-evolution/blob/ReplaceTernary/proposals/00-Replace ?: Ternary Operator with if-then-else expression.md

···

On Mon, Dec 14, 2015 at 10:41 PM, 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

Is this new syntax helping?

return if a < b
then if b < c
then b
else if a < c
then c
else a
else if a < c
then a
else if b < c
then c
else b

I found this translation quite tricky to do. maybe parens help?

return (if a < b
then (if b < c
then b
else (if a < c
then c
else a))
else (if a < c
then a
else (if b < c
then c
else b)))

Not really and I still I found this hugely frustrating, so much so that I
am going to drop all support for this proposal and remove my name from it.
If anyone wants to take over feel free.

Others still keen on the idea should try this experiment. It convinced me
is horrible idea :-) I don’t want to be blamed for it by every Swift
programmer in the future.

I do still however like the Swift Expressions.

- Paul

On Dec 14, 2015, at 4:50 PM, Nick Shelley via swift-evolution < > swift-evolution@swift.org> wrote:

I however frequently hear people saying ternary should be avoided because

they are hard to read or they hate them.

FWIW, I used to be one of those people, but then started working on a team
where one member liked them. He didn't force them on us, but after enough
code reviews where he showed us how to turn 5-line if/else statements into
simple one-line ternary expressions, I got used to reading them and now
love them and use them often.

People also hate map, flatMap, reduce, etc., for the same reasons (it's
hard for them to read because it's not the for loop they're used to). I
think it's a simple matter of getting used to it.

On Mon, Dec 14, 2015 at 11:57 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution < >> swift-evolution@swift.org> wrote:

Once again, thank you for all the feedback, if I sound in anyway grumpy
in responding to any email, it has a bit more to do with my cold than the
suggestions.

I have split the original proposal into two proposals and incorporated a
bunch of feedback. Splitting it up has been extremely good, not only does
it improve readability, I am actually finding I could take or leave the
ternary replacement idea. But the proposal will be there if enough everyone
thinks it is a good idea. We could put it to a vote to see if there is
enough interest and I would be happy to take it further if there is. I
suspect this thread would not exist at all if there was no interest in it.
However, I am finding I am far more interested in getting switch
expressions.

Ternary Replacement
https://github.com/possen/swift-evolution/blob/master/0021.md

Quick comment. The proposal states:

Is it really better? Why not just keep ternary expressions?
This is a valid question, there is an advantage in compactness to ternary
expressions. I however frequently hear people saying ternary should be
avoided because they are hard to read or they hate them. There seems to
many who either stronly dislike it or don't care.

However, it doesn’t actually show that it is solving the objections
people have to the ternary operator. It is true that some people find the
?: syntax weird, but an equal number of people say that the problem is that
you’re putting complex conditional logic inline into the middle of an
expression - this proposal actually makes that objection worse. There are
also other objections to ?:, and until you enumerate them, it is hard to
see whether this proposal is making things better or worse.

-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

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

[Al_Skipp]

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

···

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

[jrose (Jordan Rose)]

Specifically on this point:

The use of 'then' is more of a modifier to the 'if' statement than a keyword so it should be possible to allow the use of then in the same way 'let required = 1 ; let convenience = 1' is legal in swift.

We can get away with this because 'required' and 'convenience' only appear in a type, where arbitrary expressions are not allowed. In this case, 'then' is a separator between two expressions. We can probably recover if the user forgets it, but only if it's a true keyword.

I'll repost what I said on another thread: when adding new syntax, it's important to consider not just complete, correct code, but also the possible error and intermediate states that the compiler and SourceKit have to deal with.

Jordan

···

On Dec 15, 2015, at 8:38 , J. Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:

Thank you Paul for the initial draft.

Here is the a draft version that I intend to submit.

https://github.com/masters3d/swift-evolution/blob/ReplaceTernary/proposals/00-Replace%20%3F:%20Ternary%20Operator%20with%20if-then-else%20expression.md

On Monday, December 14, 2015, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto: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

Is this new syntax helping?

    return if a < b
  then if b < c
    then b
          else if a < c
       then c
       else a
  else if a < c
    then a
    else if b < c
             then c
       else b

I found this translation quite tricky to do. maybe parens help?

    return (if a < b
  then (if b < c
    then b
          else (if a < c
       then c
       else a))
  else (if a < c
    then a
    else (if b < c
             then c
       else b)))

Not really and I still I found this hugely frustrating, so much so that I am going to drop all support for this proposal and remove my name from it. If anyone wants to take over feel free.

Others still keen on the idea should try this experiment. It convinced me is horrible idea :-) I don’t want to be blamed for it by every Swift programmer in the future.

I do still however like the Swift Expressions.

- Paul

On Dec 14, 2015, at 4:50 PM, Nick Shelley via swift-evolution <swift-evolution@swift.org <>> wrote:

I however frequently hear people saying ternary should be avoided because they are hard to read or they hate them.

FWIW, I used to be one of those people, but then started working on a team where one member liked them. He didn't force them on us, but after enough code reviews where he showed us how to turn 5-line if/else statements into simple one-line ternary expressions, I got used to reading them and now love them and use them often.

People also hate map, flatMap, reduce, etc., for the same reasons (it's hard for them to read because it's not the for loop they're used to). I think it's a simple matter of getting used to it.

On Mon, Dec 14, 2015 at 11:57 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <>> wrote:

On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <>> wrote:

Once again, thank you for all the feedback, if I sound in anyway grumpy in responding to any email, it has a bit more to do with my cold than the suggestions.

I have split the original proposal into two proposals and incorporated a bunch of feedback. Splitting it up has been extremely good, not only does it improve readability, I am actually finding I could take or leave the ternary replacement idea. But the proposal will be there if enough everyone thinks it is a good idea. We could put it to a vote to see if there is enough interest and I would be happy to take it further if there is. I suspect this thread would not exist at all if there was no interest in it. However, I am finding I am far more interested in getting switch expressions.

Ternary Replacement
https://github.com/possen/swift-evolution/blob/master/0021.md

Quick comment. The proposal states:

Is it really better? Why not just keep ternary expressions?
This is a valid question, there is an advantage in compactness to ternary expressions. I however frequently hear people saying ternary should be avoided because they are hard to read or they hate them. There seems to many who either stronly dislike it or don't care.

However, it doesn’t actually show that it is solving the objections people have to the ternary operator. It is true that some people find the ?: syntax weird, but an equal number of people say that the problem is that you’re putting complex conditional logic inline into the middle of an expression - this proposal actually makes that objection worse. There are also other objections to ?:, and until you enumerate them, it is hard to see whether this proposal is making things better or worse.

-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

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

[Chris_Lattner1 (Chris Lattner)]

Random comment, but in your code examples like this:

let color = (if stop then Color.red else Color.green)

I’d suggest including the existing ternary version. The proposal is really about replacing ternary with this syntax, so it should show the “before and after”, not just the after. Your pitch is that code will look better / be easier to read if this proposal goes through, so you should demonstrate that.

-Chris

···

On Dec 15, 2015, at 8:39 AM, J. Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:

Thank you Paul for the initial draft.

Here is the a draft version that I intend to submit.

https://github.com/masters3d/swift-evolution/blob/ReplaceTernary/proposals/00-Replace%20%3F:%20Ternary%20Operator%20with%20if-then-else%20expression.md

[dennislysenko]

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

[trs (Thorsten Seitz)]

If we keep the ternary operator as "if-expression" for its succinctness,
I'd like to refresh the proposal of I-don't-remember-whom of having a similar
switch-expression:

let x = color ?
        case .Red: red
        case .Green: green
        default: black

The "case"s nicely separate the expressions and they even have colons ;-)
I'd keep the "case" keywords for three reasons: first, parsing, second, similarity
to the switch statement and third, readability (otherwise it would be really difficult
to discern case patterns from results).

-Thorsten

···

Am 15.12.2015 um 11:34 schrieb Al Skipp via swift-evolution <swift-evolution@swift.org>:

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

[masters3d]

Got it. I'll revise this. Thank you.

···

On Tuesday, December 15, 2015, Jordan Rose <jordan_rose@apple.com> wrote:

Specifically on this point:

The use of 'then' is more of a modifier to the 'if' statement than a
keyword so it should be possible to allow the use of then in the same
way 'let required = 1 ; let convenience = 1' is legal in swift.

We can get away with this because 'required' and 'convenience' only appear
in a type, where arbitrary expressions are not allowed. In this case,
'then' is a separator between two expressions. We can probably recover if
the user forgets it, but only if it's a true keyword.

I'll repost what I said on another thread: when adding new syntax, it's
important to consider not just complete, correct code, but also the
possible error and intermediate states that the compiler and SourceKit have
to deal with.

Jordan

On Dec 15, 2015, at 8:38 , J. Cheyo Jimenez via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Thank you Paul for the initial draft.

Here is the a draft version that I intend to submit.

https://github.com/masters3d/swift-evolution/blob/ReplaceTernary/proposals/00-Replace%20%3F:%20Ternary%20Operator%20with%20if-then-else%20expression.md

On Monday, December 14, 2015, Paul Ossenbruggen via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','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

Is this new syntax helping?

return if a < b
then if b < c
then b
else if a < c
then c
else a
else if a < c
then a
else if b < c
then c
else b

I found this translation quite tricky to do. maybe parens help?

return (if a < b
then (if b < c
then b
else (if a < c
then c
else a))
else (if a < c
then a
else (if b < c
then c
else b)))

Not really and I still I found this hugely frustrating, so much so that I
am going to drop all support for this proposal and remove my name from it.
If anyone wants to take over feel free.

Others still keen on the idea should try this experiment. It convinced me
is horrible idea :-) I don’t want to be blamed for it by every Swift
programmer in the future.

I do still however like the Swift Expressions.

- Paul

On Dec 14, 2015, at 4:50 PM, Nick Shelley via swift-evolution < >> swift-evolution@swift.org> wrote:

I however frequently hear people saying ternary should be avoided because

they are hard to read or they hate them.

FWIW, I used to be one of those people, but then started working on a
team where one member liked them. He didn't force them on us, but after
enough code reviews where he showed us how to turn 5-line if/else
statements into simple one-line ternary expressions, I got used to reading
them and now love them and use them often.

People also hate map, flatMap, reduce, etc., for the same reasons (it's
hard for them to read because it's not the for loop they're used to). I
think it's a simple matter of getting used to it.

On Mon, Dec 14, 2015 at 11:57 AM, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote:

On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution < >>> swift-evolution@swift.org> wrote:

Once again, thank you for all the feedback, if I sound in anyway grumpy
in responding to any email, it has a bit more to do with my cold than the
suggestions.

I have split the original proposal into two proposals and incorporated a
bunch of feedback. Splitting it up has been extremely good, not only does
it improve readability, I am actually finding I could take or leave the
ternary replacement idea. But the proposal will be there if enough everyone
thinks it is a good idea. We could put it to a vote to see if there is
enough interest and I would be happy to take it further if there is. I
suspect this thread would not exist at all if there was no interest in it.
However, I am finding I am far more interested in getting switch
expressions.

Ternary Replacement
https://github.com/possen/swift-evolution/blob/master/0021.md

Quick comment. The proposal states:

Is it really better? Why not just keep ternary expressions?
This is a valid question, there is an advantage in compactness to
ternary expressions. I however frequently hear people saying ternary should
be avoided because they are hard to read or they hate them. There seems to
many who either stronly dislike it or don't care.

However, it doesn’t actually show that it is solving the objections
people have to the ternary operator. It is true that some people find the
?: syntax weird, but an equal number of people say that the problem is that
you’re putting complex conditional logic inline into the middle of an
expression - this proposal actually makes that objection worse. There are
also other objections to ?:, and until you enumerate them, it is hard to
see whether this proposal is making things better or worse.

-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

_______________________________________________

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

[possen (Paul Ossenbruggen)]

Yeah I believe we did discuss this a bit. I like it.

···

On Dec 15, 2015, at 1:29 PM, Thorsten Seitz <tseitz42@icloud.com> wrote:

If we keep the ternary operator as "if-expression" for its succinctness,
I'd like to refresh the proposal of I-don't-remember-whom of having a similar
switch-expression:

let x = color ?
        case .Red: red
        case .Green: green
        default: black

The "case"s nicely separate the expressions and they even have colons ;-)
I'd keep the "case" keywords for three reasons: first, parsing, second, similarity
to the switch statement and third, readability (otherwise it would be really difficult
to discern case patterns from results).

-Thorsten

Am 15.12.2015 um 11:34 schrieb Al Skipp via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

On 15 Dec 2015, at 06:41, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Charles_Constant]

+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!

[dennislysenko]

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

[possen (Paul Ossenbruggen)]

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> 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
https://lists.swift.org/mailman/listinfo/swift-evolution