ternary operator ?: suggestion

masters3d · December 12, 2015, 7:33pm

There are a couple of languages that use then inside their switches.
http://rigaux.org/language-study/syntax-across-languages.html#CntrFlowMltSlcSwt

I like using only one then in the switch to signal to the parser that this
is a switch expression

The only issue I see is that the colon in the switch is used in the same
way as the current ternary expression.

Personally I don't think that a switch expression is all that useful since
being a multiline statement actually helps the readability.

var result:Int = {if bool {return 1} else if bool {return 2} else {return 3
}}()

VS

var result = if bool then 1 else if bool then 2 else 3

···

On Sat, Dec 12, 2015 at 11:15 AM, Al Skipp via swift-evolution < swift-evolution@swift.org> wrote:

On 12 Dec 2015, at 14:48, Paul Ossenbruggen <possen@gmail.com> wrote:

Dropping “case” might be interesting, since it becomes a little redundant
in the “switch” situation, this is one advantage of having a new
keyword, but not sure this reads as well:

let v = switch val then .Red: 1, .Green: 2, .Blue: 3

It is definitely nice in it’s compactness which is a big plus.

Another possibility, because “switch" does not need to resolve the
syntactic ambiguity, but then we lose the “then” always meaning an
expression consistency.

let v = switch val case .Red: 1, case .Green: 2, case .Blue: 3

this might be better for switch because we don’t need to mix “then” with
“switch” which historically has not been done. Question is, is it better to
go with “then” as expression consistency or with slightly more compact and
following the conventions out there. Personally, I am not bothered by using
“then” with “switch”

Would the cases need to be comma separated? Would a new line make more
sense instead?

Currently this is possible:

enum Col { case Red, Green, Blue }

let c = Col.Blue

let x: Int = {
  switch c {
  case .Red: return 1
  case .Green: return 2
  case .Blue: return 3
  }
}()

It works, but there are several things I don’t like:
- the switch statement must be wrapped in a closure which is invoked at
the end.
- the type of ‘x’ needs to be given
- each case requires a return statement

Here’s a proposal for a switch expression:

let y = switch c then {
  .Red: 1
  .Green: 2
  .Blue: 3
}

I think the braces are probably needed in the switch expression, also the
‘then’ keyword’ does look a bit peculiar. Any other ideas on how to support
both switch statements and expressions?

Al

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

possen · December 12, 2015, 8:42pm

It is pretty cool your example that works with the existing Swift and I agree with your assessment of it, but good to know.

I would prefer not to have the brackets in the expressions if possible, Bracket seem a little weird to me inside of an expression. This could also serve to further differentiate a statement vs expression in people’s minds. If the rule is use braces for statements, and no brackets for expressions. If we needed to use something like a bracket, parenthesis seem more natural for an expression but I think it is better avoid the need for them if possible. Also, not having brackets or parenthesis looks cleaner to me. The commas allow the statement continue without having braces or parenthesis. Keep in mind compounded expressions, having required braces in this example would make it much harder to read:

let v = switch val then .Red: 1, .Green: (if specialGreen then 5 else 2), .Blue: (switch shade then .DarkBlue: 6, .LightBlue: 7, default: 9), default: 4

Use of “then" for the switch expression kind of works if we also want to drop the “case:”. We could use another keyword like “cases” but in general the consensus is to avoid adding keywords unless necessary and “then” with this suggestion, would already be added for “if”. To explore this idea a bit:

let v = switch val cases: .Red: 1, .Green: 2, .Blue: 3, default: 4

this might be more in line with the existing “switch...case” syntax. It seems that this should also work in statements:

switch val {
  cases: .Red: func1(),
      .Green: func2(),
      .Blue: func3(),
  default: func4()
}

This is kind of nice because it reduces the repetition of the word “case:” as well as decreasing visual clutter present in a switch statement. Going back to the expression, it would also be possible to write it like this, if preferred:

let v = switch val case: .Red: 1, case: .Green: 2, case: .Blue: 3, default: 4

For consistency “cases:” could be allowed here...from your example:

enum Col { cases: Red, Green, Blue }

I suppose as an alternative rather than adding the plural of “case” just use “case:” because it is an existing keyword, as in this example but I think it reads clearer with the plural.

···

On Dec 12, 2015, at 11:15 AM, Al Skipp <al_skipp@fastmail.fm> wrote:

On 12 Dec 2015, at 14:48, Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>> wrote:

Dropping “case” might be interesting, since it becomes a little redundant in the “switch” situation, this is one advantage of having a new keyword, but not sure this reads as well:

let v = switch val then .Red: 1, .Green: 2, .Blue: 3

It is definitely nice in it’s compactness which is a big plus.

Another possibility, because “switch" does not need to resolve the syntactic ambiguity, but then we lose the “then” always meaning an expression consistency.

let v = switch val case .Red: 1, case .Green: 2, case .Blue: 3

this might be better for switch because we don’t need to mix “then” with “switch” which historically has not been done. Question is, is it better to go with “then” as expression consistency or with slightly more compact and following the conventions out there. Personally, I am not bothered by using “then” with “switch”

Would the cases need to be comma separated? Would a new line make more sense instead?

Currently this is possible:

enum Col { case Red, Green, Blue }

let c = Col.Blue

let x: Int = {
  switch c {
  case .Red: return 1
  case .Green: return 2
  case .Blue: return 3
  }
}()

It works, but there are several things I don’t like:
- the switch statement must be wrapped in a closure which is invoked at the end.
- the type of ‘x’ needs to be given
- each case requires a return statement

Here’s a proposal for a switch expression:

let y = switch c then {
  .Red: 1
  .Green: 2
  .Blue: 3
}

I think the braces are probably needed in the switch expression, also the ‘then’ keyword’ does look a bit peculiar. Any other ideas on how to support both switch statements and expressions?

Al

possen · December 13, 2015, 5:17pm

I also have no preference yet so I'll just throw in some thoughts.

** Existing Code **
The removal of the ternary operator would likely affect a lot of existing code.
A quick search for " ? " (with spaces) over a large app of our team yields 304 results.

Two simpler examples:

[
    "With Conditions": hasReport ? "yes" : "no",
    "With Image": hasImage ? "yes" : "no",
    "With Message": hasMessage ? "yes" : "no",
    "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
    "Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",
    "Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"
]

view1.alpha = editing ? 1 : 0
view2.alpha = editing ? 1 : 0
view3.alpha = editing ? 0 : 1
view4.alpha = editing ? 1 : 0

I am not sure using if…then…else would make this better to read & understand or worse.

there seems to be a lot of people who dislike ternary operators. Other languages also are similar in dumping ternary.

** Keyword then **
Making then a keyword would also cost us another word so that change needs to be carefully considered.
In our large app I found just a single instance where then was used for a variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }
Promises use the word then rather extensively: https://promisesaplus.com <https://promisesaplus.com/>

Good point. Will think about it.

···

On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc@knaup.koeln> wrote:

On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm not quite sure how I feel about this specific proposal yet but in general I do want to see conditional expressions and removal of the ternary operator.

I would like to see "else if" included in whatever we adopt as the final solution. Is there a reason this is omitted from this proposal? I apologize if that was discussed in the thread. I haven't followed every post.

Sent from my iPad

On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>> wrote:

Implied in using the “then", if…then…else would aways require “else" when using “then” similar to how “guard" requires “else”. This will help to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>> wrote:

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

1. I would really hate to explain to someone when if needs a then and when it doesn't. That's the sort of inconsistency that shouldn't be added lightly.

agreed definitely want to be careful with that. I think with braces meaning statements that differentiation can be made clear. I would certainly start with statements when describing, just as you usually don’t talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for replacing (A ? B : C) with some sort of (if A then B else C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify every outcome:

if cond {
print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

masters3d · December 13, 2015, 8:04pm

Ha. Disregard. I misread this.

···

On Sunday, December 13, 2015, J. Cheyo Jimenez <cheyo@masters3d.com> wrote:

"or we could go with an optional “then” for statements as was suggested by
Thorsten. "

I don't think this should go in the proposal. An else is alway required in
a guard statement, an expression should not return an optional imho.

On Sunday, December 13, 2015, Paul Ossenbruggen via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

On Dec 13, 2015, at 8:11 AM, Jakob Egger <jakob@eggerapps.at> wrote:

I really don't like the "if cond then expr1 else expr2".

1) First of all, it's extremely verbose. It's almost as bad as the SQL
construct "case when cond then expr1 else expr2 end”.

Yeah it adds a few characters overall. What used to be 2 chars now takes
10. Clarity is preferred though by many. I head frequently people telling
users to never use ternary operators because they are confusing to read.

2) It makes Swift harder to learn. Newcomers will be confused why you
sometimes need to use curly braces and why at other times you need to use
the "then" keyword.

I did mention this in Alternatives Considered section. By making the else
part required, this emphasizes that it is different or we could go with an
optional “then” for statements as was suggested by Thorsten.

3) It doesn't help when you want to do multi-line calculations

This is the case with the ternary as well, I think it is better to keep
it simple.

But there is one good side to this proposal: it nests more naturally than
the ternary operator:
"if cond then expr1 else if cond2 then expr2 else expr3"
vs.
"cond ? expr1 : (cond2 ? expr2 : expr3)

The proposed syntax for the switch statement is so confusing that I
really don't think it is a good idea.

Not sure why that is, it is essentially the same as the existing switch
statement except everything is an expression instead of statements. Is
there anything I can do in the examples or documentation to make things
clearer?

Why not just allow normal if statements to return values?
I don't see what's so bad about the following:
"let value = if cond {expr1} else {expr2}"

This would also extend to multiple lines:
let value = if cond {
  expr1
} else {
  let something = Object()
  something.doStuff()
  something
}

I answered this with others, also notice how there are braces everywhere?
does that really work when you just want to put something on one line. What
happens when one of your branches returns void? Expressions are guaranteed
to have a result, statements don’t make such a guarantee.

Jakob

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

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and
switch expressions based upon the discussions we had here. I have tried to
keep the scope of the changes as small as possible, only added one keyword
and kept things as similar to the existing language constructs as possible.
If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

fluidsonic · December 13, 2015, 2:14pm

Another thought:

The ternary operator uses the characters "?" and ":" very differently from
the rest of the language where they relate to optionals (?) and type
declarations/method parameters (:).

···

On Sun, Dec 13, 2015 at 3:11 PM, Marc Knaup <marc@knaup.koeln> wrote:

I also have no preference yet so I'll just throw in some thoughts.

** Existing Code **
The removal of the ternary operator would likely affect a lot of existing
code.
A quick search for " ? " (with spaces) over a large app of our team yields
304 results.

Two simpler examples:

[
  "With Conditions": hasReport ? "yes" : "no",
  "With Image": hasImage ? "yes" : "no",
  "With Message": hasMessage ? "yes" : "no",
  "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
  "Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",
  "Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"
]

view1.alpha = editing ? 1 : 0
view2.alpha = editing ? 1 : 0
view3.alpha = editing ? 0 : 1
view4.alpha = editing ? 1 : 0

I am not sure using if…then…else would make this better to read &
understand or worse.

** Keyword then **
Making then a keyword would also cost us another word so that change needs
to be carefully considered.
In our large app I found just a single instance where then was used for a
variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }

Promises use the word then rather extensively: https://promisesaplus.com

On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:

I'm not quite sure how I feel about this specific proposal yet but in
general I do want to see conditional expressions and removal of the ternary
operator.

I would like to see "else if" included in whatever we adopt as the final
solution. Is there a reason this is omitted from this proposal? I
apologize if that was discussed in the thread. I haven't followed every
post.

Sent from my iPad

On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution < >> swift-evolution@swift.org> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and
switch expressions based upon the discussions we had here. I have tried to
keep the scope of the changes as small as possible, only added one keyword
and kept things as similar to the existing language constructs as possible.
If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

Implied in using the “then", if…then…else would aways require “else"
when using “then” similar to how “guard" requires “else”. This will help
to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution < >> swift-evolution@swift.org> wrote:

1. I would really hate to explain to someone when *if* needs a *then*
and when it doesn't. That's the sort of inconsistency that shouldn't be
added lightly.

agreed definitely want to be careful with that. I think with braces
meaning statements that differentiation can be made clear. I would
certainly start with statements when describing, just as you usually don’t
talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for replacing
(A ? B : C) with some sort of (*if* A *then* B *else* C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be
usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify
every outcome:

if cond {
print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

trs · December 13, 2015, 2:53pm

In that case we should probably refrain from introducing „then“ (or can the parser differentiate these usages, so that „then“ is still available for variables?

Rust is just using the statement form for the if-expression:

let x = if condition { … } else { … }

Rust allows having several statements in each block with the last having to be an expression which is used as value for the branch, effectively treating the { … } as closure and evaluating it for the branch executed.

Chris Lattner didn’t like using { … } in the if-expression, but I didn’t understand why, I have to admit.

-Thorsten

···

Am 13.12.2015 um 15:11 schrieb Marc Knaup via swift-evolution <swift-evolution@swift.org>:

** Keyword then **
Making then a keyword would also cost us another word so that change needs to be carefully considered.
In our large app I found just a single instance where then was used for a variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }
Promises use the word then rather extensively: https://promisesaplus.com <https://promisesaplus.com/>That’s a good point, Marc!

fluidsonic · December 13, 2015, 3:33pm

It's part of this one:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002056.html

···

On Sun, Dec 13, 2015 at 4:25 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

Thanks everyone for the feedback! I will look at it in detail and address
or incorporate what makes sense for the proposed approach.

Using fully-fledged if/switch-statements as expressions is another
proposal and discussion (which already exists).

can you point me to this?

On Dec 13, 2015, at 7:09 AM, Marc Knaup via swift-evolution < > swift-evolution@swift.org> wrote:

Using fully-fledged if/switch-statements as expressions is another
proposal and discussion (which already exists).

The replacement of the ternary operator should be just syntactic sugar for
the other proposal to have a shorter version of "let x = if a {} else {}".

Regarding the "then" keyword:
What about "do"?

let x = if a do b else c

Yes, it reads a bit weird, but as if & switch statements are moving
towards being expressions already then "do" blocks will likely too.

So the above example would just be another shortcut for

let x = if a { do { b } } else { c }

On Sun, Dec 13, 2015 at 3:56 PM, Taras Zakharko via swift-evolution < > swift-evolution@swift.org> wrote:

Hi Paul,

what bothers me in your proposal is that you seem to allow only simple
expressions. But it is often the case that one needs to have multiple
statements to set up the value. For example:

  let data = if connection.valid
    connection.cached_data
  else {
    // generate the data again
}

I have been thinking a bit about how to implement this in connection
with the idea of code blocks as closures proposal I have posted earlier (
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002056.html\).
Switch is a bit more complicated, but I think that the existing if
statement can be easily turned into expression:

   func if_<T>(condition: Bool, then_: (()->T)?, else_: (()->T)?) -> T? {
    var result: T?

    if condition {
        result = then_?()
    } else {
        result = else_?()
    }

    return result
}

the compiler would then translate all if statements into

   if_(condition, then_: then block, else_: else block)

if the else block is not present, it will be set to nil. In that case the
if expression also evaluates to nil. Now, if the if is used as a statement,
the above transformation is sufficient and the return value will be
optimised away by the compiler. If the expression form is used (i.e. there
is an assignment operation), the compiler will forcefully unwrap the result:

let x = if_(condition, then_: then block, else_: else block)!

This way, if else block is absent, the program will crash. A bit of
tweaking will also generate a useful error message. I am also sure that it
is possible to generate a warning (or even an error) at the compile time
without too much effort.

I think the nice thing about this proposal is that it uses already
existing mechanisms in the language and only requires some minimal
transformations by the compiler.

The switch expression can be approached in a similar way, but would
require more compiler magic.

Best,

Taras

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

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and
switch expressions based upon the discussions we had here. I have tried to
keep the scope of the changes as small as possible, only added one keyword
and kept things as similar to the existing language constructs as possible.
If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

Implied in using the “then", if…then…else would aways require “else"
when using “then” similar to how “guard" requires “else”. This will help
to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution < >> swift-evolution@swift.org> wrote:

1. I would really hate to explain to someone when *if* needs a *then* and
when it doesn't. That's the sort of inconsistency that shouldn't be added
lightly.

agreed definitely want to be careful with that. I think with braces
meaning statements that differentiation can be made clear. I would
certainly start with statements when describing, just as you usually don’t
talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for replacing
(A ? B : C) with some sort of (*if* A *then* B *else* C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be
usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify
every outcome:

if cond {
print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

trs · December 14, 2015, 4:24pm

I think there's been a misunderstanding or two...

First I proposed that if if-expressions would be written with "then" then if-statements should use "then", too, for consistency. Always, not optionally.

Second I would require if-expressions to always have an "else" clause (as opposed to proposals that suggested to interpret missing "else" clauses as "else nil", i.e making the result type of the if-expression optional).

-Thorsten

···

Am 13.12.2015 um 20:50 schrieb J. Cheyo Jimenez via swift-evolution <swift-evolution@swift.org>:

"or we could go with an optional “then” for statements as was suggested by Thorsten. "

I don't think this should go in the proposal. An else is alway required in a guard statement, an expression should not return an optional imho.

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

On Dec 13, 2015, at 8:11 AM, Jakob Egger <jakob@eggerapps.at> wrote:

I really don't like the "if cond then expr1 else expr2".

1) First of all, it's extremely verbose. It's almost as bad as the SQL construct "case when cond then expr1 else expr2 end”.

Yeah it adds a few characters overall. What used to be 2 chars now takes 10. Clarity is preferred though by many. I head frequently people telling users to never use ternary operators because they are confusing to read.

2) It makes Swift harder to learn. Newcomers will be confused why you sometimes need to use curly braces and why at other times you need to use the "then" keyword.

I did mention this in Alternatives Considered section. By making the else part required, this emphasizes that it is different or we could go with an optional “then” for statements as was suggested by Thorsten.

3) It doesn't help when you want to do multi-line calculations

This is the case with the ternary as well, I think it is better to keep it simple.

But there is one good side to this proposal: it nests more naturally than the ternary operator:
"if cond then expr1 else if cond2 then expr2 else expr3"
vs.
"cond ? expr1 : (cond2 ? expr2 : expr3)

The proposed syntax for the switch statement is so confusing that I really don't think it is a good idea.

Not sure why that is, it is essentially the same as the existing switch statement except everything is an expression instead of statements. Is there anything I can do in the examples or documentation to make things clearer?

Why not just allow normal if statements to return values?
I don't see what's so bad about the following:
"let value = if cond {expr1} else {expr2}"

This would also extend to multiple lines:
let value = if cond {
  expr1
} else {
  let something = Object()
  something.doStuff()
  something
}

I answered this with others, also notice how there are braces everywhere? does that really work when you just want to put something on one line. What happens when one of your branches returns void? Expressions are guaranteed to have a result, statements don’t make such a guarantee.

Jakob

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

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

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

Al_Skipp · December 12, 2015, 8:23pm

There are a couple of languages that use then inside their switches.
syntax across languages (One Big Page)

I like using only one then in the switch to signal to the parser that this is a switch expression

The only issue I see is that the colon in the switch is used in the same way as the current ternary expression.

Good point. This probably makes more sense:

let y = switch c {
  .Red then 1
  .Green then 2
  .Blue then 3
}

Personally I don't think that a switch expression is all that useful since being a multiline statement actually helps the readability.

I think it can cut down on unnecessary boilerplate code, especially in functions that contain pattern matching and return a value. In which case you need to declare a variable, do the switch, assign to the var, then return at the end. It’s possible to do the trick with wrapping the switch in a closure inside the function, but that’s also quite ugly. It’d be nice to be able to do:

func f(c: Col) -> Int {
  return switch c {
    .Red then 1
    .Green then 2
    .Blue then 3
  }
}

···

On 12 Dec 2015, at 19:33, J. Cheyo Jimenez <cheyo@masters3d.com> wrote:

dennislysenko · December 13, 2015, 6:18pm

Just wanted to add, in regards to the argument of "why use 'then' rather
than keeping 'if condition { A } else { B }'?": besides my personal opinion
that inline braces look out-of-place, braces behave specially in xcode and
are notorious for screwing up indentation. For example, since swift was
released, multiple non-trailing closure arguments to a single function call
(e.g. MagicalRecord.saveWithBlock) are indented inconsistently, with the
second closure one indentation level higher than the first. More
generally/summarily, braces carry special indentation rules that do not
necessarily suit expressions.

···

On Sun, Dec 13, 2015, 12:17 PM Paul Ossenbruggen via swift-evolution < swift-evolution@swift.org> wrote:

On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc@knaup.koeln> wrote:

I also have no preference yet so I'll just throw in some thoughts.

** Existing Code **
The removal of the ternary operator would likely affect a lot of existing
code.
A quick search for " ? " (with spaces) over a large app of our team yields
304 results.

Two simpler examples:

[
  "With Conditions": hasReport ? "yes" : "no",
  "With Image": hasImage ? "yes" : "no",
  "With Message": hasMessage ? "yes" : "no",
  "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
  "Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",
  "Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"
]

view1.alpha = editing ? 1 : 0
view2.alpha = editing ? 1 : 0
view3.alpha = editing ? 0 : 1
view4.alpha = editing ? 1 : 0

I am not sure using if…then…else would make this better to read &
understand or worse.

there seems to be a lot of people who dislike ternary operators. Other
languages also are similar in dumping ternary.

** Keyword then **
Making then a keyword would also cost us another word so that change needs
to be carefully considered.
In our large app I found just a single instance where then was used for a
variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }

Promises use the word then rather extensively: https://promisesaplus.com

Good point. Will think about it.

On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:

I'm not quite sure how I feel about this specific proposal yet but in
general I do want to see conditional expressions and removal of the ternary
operator.

I would like to see "else if" included in whatever we adopt as the final
solution. Is there a reason this is omitted from this proposal? I
apologize if that was discussed in the thread. I haven't followed every
post.

Sent from my iPad

On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution < >> swift-evolution@swift.org> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and
switch expressions based upon the discussions we had here. I have tried to
keep the scope of the changes as small as possible, only added one keyword
and kept things as similar to the existing language constructs as possible.
If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

Implied in using the “then", if…then…else would aways require “else"
when using “then” similar to how “guard" requires “else”. This will help
to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution < >> swift-evolution@swift.org> wrote:

1. I would really hate to explain to someone when *if* needs a *then*
and when it doesn't. That's the sort of inconsistency that shouldn't be
added lightly.

agreed definitely want to be careful with that. I think with braces
meaning statements that differentiation can be made clear. I would
certainly start with statements when describing, just as you usually don’t
talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for replacing
(A ? B : C) with some sort of (*if* A *then* B *else* C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be
usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify
every outcome:

if cond {
print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

possen · December 15, 2015, 4:47am

Yeah, I attributed adding “then” to statements to you but I added that it not be required. I did not want it to be required both because personally I like just putting the brace after the conditional, it not necessary in the statement form, and where possible I like to avoid visual clutter as much as possible. The benefit to new users is that don’t need to worry about when to use then. This helps with the consistency of the two forms and what current Swift users are used to. Also, it does not break existing code.

···

On Dec 14, 2015, at 8:24 AM, Thorsten Seitz <tseitz42@icloud.com> wrote:

I think there's been a misunderstanding or two...

First I proposed that if if-expressions would be written with "then" then if-statements should use "then", too, for consistency. Always, not optionally.

Second I would require if-expressions to always have an "else" clause (as opposed to proposals that suggested to interpret missing "else" clauses as "else nil", i.e making the result type of the if-expression optional).

-Thorsten

Am 13.12.2015 um 20:50 schrieb J. Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

"or we could go with an optional “then” for statements as was suggested by Thorsten. "

I don't think this should go in the proposal. An else is alway required in a guard statement, an expression should not return an optional imho.

On Sunday, December 13, 2015, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 13, 2015, at 8:11 AM, Jakob Egger <jakob@eggerapps.at <javascript:_e(%7B%7D,'cvml','jakob@eggerapps.at');>> wrote:

I really don't like the "if cond then expr1 else expr2".

1) First of all, it's extremely verbose. It's almost as bad as the SQL construct "case when cond then expr1 else expr2 end”.

Yeah it adds a few characters overall. What used to be 2 chars now takes 10. Clarity is preferred though by many. I head frequently people telling users to never use ternary operators because they are confusing to read.

2) It makes Swift harder to learn. Newcomers will be confused why you sometimes need to use curly braces and why at other times you need to use the "then" keyword.

I did mention this in Alternatives Considered section. By making the else part required, this emphasizes that it is different or we could go with an optional “then” for statements as was suggested by Thorsten.

3) It doesn't help when you want to do multi-line calculations

This is the case with the ternary as well, I think it is better to keep it simple.

But there is one good side to this proposal: it nests more naturally than the ternary operator:
"if cond then expr1 else if cond2 then expr2 else expr3"
vs.
"cond ? expr1 : (cond2 ? expr2 : expr3)

The proposed syntax for the switch statement is so confusing that I really don't think it is a good idea.

Not sure why that is, it is essentially the same as the existing switch statement except everything is an expression instead of statements. Is there anything I can do in the examples or documentation to make things clearer?

Why not just allow normal if statements to return values?
I don't see what's so bad about the following:
"let value = if cond {expr1} else {expr2}"

This would also extend to multiple lines:
let value = if cond {
  expr1
} else {
  let something = Object()
  something.doStuff()
  something
}

I answered this with others, also notice how there are braces everywhere? does that really work when you just want to put something on one line. What happens when one of your branches returns void? Expressions are guaranteed to have a result, statements don’t make such a guarantee.

Jakob

On 13 Dec 2015, at 06:54, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

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

possen · December 13, 2015, 7:36pm

I agree that keeping braces out of these expressions reads much better also it serves to differentiate statements vs expressions.

···

On Dec 13, 2015, at 10:18 AM, Dennis Lysenko <dennis.s.lysenko@gmail.com> wrote:

Just wanted to add, in regards to the argument of "why use 'then' rather than keeping 'if condition { A } else { B }'?": besides my personal opinion that inline braces look out-of-place, braces behave specially in xcode and are notorious for screwing up indentation. For example, since swift was released, multiple non-trailing closure arguments to a single function call (e.g. MagicalRecord.saveWithBlock) are indented inconsistently, with the second closure one indentation level higher than the first. More generally/summarily, braces carry special indentation rules that do not necessarily suit expressions.

On Sun, Dec 13, 2015, 12:17 PM Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc@knaup.koeln <mailto:marc@knaup.koeln>> wrote:

I also have no preference yet so I'll just throw in some thoughts.

** Existing Code **
The removal of the ternary operator would likely affect a lot of existing code.
A quick search for " ? " (with spaces) over a large app of our team yields 304 results.

Two simpler examples:

[
    "With Conditions": hasReport ? "yes" : "no",
    "With Image": hasImage ? "yes" : "no",
    "With Message": hasMessage ? "yes" : "no",
    "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
    "Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",
    "Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"
]

view1.alpha = editing ? 1 : 0
view2.alpha = editing ? 1 : 0
view3.alpha = editing ? 0 : 1
view4.alpha = editing ? 1 : 0

I am not sure using if…then…else would make this better to read & understand or worse.

there seems to be a lot of people who dislike ternary operators. Other languages also are similar in dumping ternary.

** Keyword then **
Making then a keyword would also cost us another word so that change needs to be carefully considered.
In our large app I found just a single instance where then was used for a variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }
Promises use the word then rather extensively: https://promisesaplus.com <https://promisesaplus.com/>

Good point. Will think about it.

On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm not quite sure how I feel about this specific proposal yet but in general I do want to see conditional expressions and removal of the ternary operator.

I would like to see "else if" included in whatever we adopt as the final solution. Is there a reason this is omitted from this proposal? I apologize if that was discussed in the thread. I haven't followed every post.

Sent from my iPad

On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>> wrote:

Implied in using the “then", if…then…else would aways require “else" when using “then” similar to how “guard" requires “else”. This will help to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>> wrote:

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

1. I would really hate to explain to someone when if needs a then and when it doesn't. That's the sort of inconsistency that shouldn't be added lightly.

agreed definitely want to be careful with that. I think with braces meaning statements that differentiation can be made clear. I would certainly start with statements when describing, just as you usually don’t talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for replacing (A ? B : C) with some sort of (if A then B else C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify every outcome:

if cond {
  print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

fluidsonic · December 13, 2015, 6:37pm

Replacing constructs like

let x = condition ? 0 : 1

with

let x = if condition { 0 } else { 1 }

is very unlikely to make working with Swift any easier.

···

On Sun, Dec 13, 2015 at 7:18 PM, Dennis Lysenko <dennis.s.lysenko@gmail.com> wrote:

Just wanted to add, in regards to the argument of "why use 'then' rather
than keeping 'if condition { A } else { B }'?": besides my personal opinion
that inline braces look out-of-place, braces behave specially in xcode and
are notorious for screwing up indentation. For example, since swift was
released, multiple non-trailing closure arguments to a single function call
(e.g. MagicalRecord.saveWithBlock) are indented inconsistently, with the
second closure one indentation level higher than the first. More
generally/summarily, braces carry special indentation rules that do not
necessarily suit expressions.

On Sun, Dec 13, 2015, 12:17 PM Paul Ossenbruggen via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc@knaup.koeln> wrote:

I also have no preference yet so I'll just throw in some thoughts.

** Existing Code **
The removal of the ternary operator would likely affect a lot of existing
code.
A quick search for " ? " (with spaces) over a large app of our team
yields 304 results.

Two simpler examples:

[
  "With Conditions": hasReport ? "yes" : "no",
  "With Image": hasImage ? "yes" : "no",
  "With Message": hasMessage ? "yes" : "no",
  "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
  "Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",
  "Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"
]

view1.alpha = editing ? 1 : 0
view2.alpha = editing ? 1 : 0
view3.alpha = editing ? 0 : 1
view4.alpha = editing ? 1 : 0

I am not sure using if…then…else would make this better to read &
understand or worse.

there seems to be a lot of people who dislike ternary operators. Other
languages also are similar in dumping ternary.

** Keyword then **
Making then a keyword would also cost us another word so that change
needs to be carefully considered.
In our large app I found just a single instance where then was used for
a variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }

Promises use the word then rather extensively: https://promisesaplus.com

Good point. Will think about it.

On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution < >> swift-evolution@swift.org> wrote:

I'm not quite sure how I feel about this specific proposal yet but in
general I do want to see conditional expressions and removal of the ternary
operator.

I would like to see "else if" included in whatever we adopt as the final
solution. Is there a reason this is omitted from this proposal? I
apologize if that was discussed in the thread. I haven't followed every
post.

Sent from my iPad

On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution < >>> swift-evolution@swift.org> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and
switch expressions based upon the discussions we had here. I have tried to
keep the scope of the changes as small as possible, only added one keyword
and kept things as similar to the existing language constructs as possible.
If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

Implied in using the “then", if…then…else would aways require “else"
when using “then” similar to how “guard" requires “else”. This will help
to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen@gmail.com> >>> wrote:

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution < >>> swift-evolution@swift.org> wrote:

1. I would really hate to explain to someone when *if* needs a *then*
and when it doesn't. That's the sort of inconsistency that shouldn't be
added lightly.

agreed definitely want to be careful with that. I think with braces
meaning statements that differentiation can be made clear. I would
certainly start with statements when describing, just as you usually don’t
talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for replacing
(A ? B : C) with some sort of (*if* A *then* B *else* C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be
usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify
every outcome:

if cond {
print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

Andrew_Brown · December 13, 2015, 7:31pm

I agree, but there seems to be a lot of support for statements as expressions for some reason. That's not something I'd be keen to move towards quickly but if we need to go there, how about a more general solution.

Let's give every statement a builtin 'return' variable - I'll use _ in the example below but I don't think it's really appropriate.

let x = if condition {
    _ = value1
  } else {
    _ = value2
  }

let width = if condition {_ = 1920} else {_ = 640}

With a default assumption that _ = void if the default, if no assignments are used, we can ensure type checking and catch cases where not all paths correctly assign to _

ABR.

···

On 13 Dec 2015, at 18:37, Marc Knaup via swift-evolution <swift-evolution@swift.org> wrote:

Replacing constructs like

let x = condition ? 0 : 1

with

let x = if condition { 0 } else { 1 }

is very unlikely to make working with Swift any easier.

On Sun, Dec 13, 2015 at 7:18 PM, Dennis Lysenko <dennis.s.lysenko@gmail.com> wrote:
Just wanted to add, in regards to the argument of "why use 'then' rather than keeping 'if condition { A } else { B }'?": besides my personal opinion that inline braces look out-of-place, braces behave specially in xcode and are notorious for screwing up indentation. For example, since swift was released, multiple non-trailing closure arguments to a single function call (e.g. MagicalRecord.saveWithBlock) are indented inconsistently, with the second closure one indentation level higher than the first. More generally/summarily, braces carry special indentation rules that do not necessarily suit expressions.

On Sun, Dec 13, 2015, 12:17 PM Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc@knaup.koeln> wrote:

I also have no preference yet so I'll just throw in some thoughts.

** Existing Code **
The removal of the ternary operator would likely affect a lot of existing code.
A quick search for " ? " (with spaces) over a large app of our team yields 304 results.

Two simpler examples:

[
    "With Conditions": hasReport ? "yes" : "no",
    "With Image": hasImage ? "yes" : "no",
    "With Message": hasMessage ? "yes" : "no",
    "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
    "Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",
    "Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"
]

view1.alpha = editing ? 1 : 0
view2.alpha = editing ? 1 : 0
view3.alpha = editing ? 0 : 1
view4.alpha = editing ? 1 : 0

I am not sure using if…then…else would make this better to read & understand or worse.

there seems to be a lot of people who dislike ternary operators. Other languages also are similar in dumping ternary.

** Keyword then **
Making then a keyword would also cost us another word so that change needs to be carefully considered.
In our large app I found just a single instance where then was used for a variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }
Promises use the word then rather extensively: https://promisesaplus.com

Good point. Will think about it.

On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
I'm not quite sure how I feel about this specific proposal yet but in general I do want to see conditional expressions and removal of the ternary operator.

I would like to see "else if" included in whatever we adopt as the final solution. Is there a reason this is omitted from this proposal? I apologize if that was discussed in the thread. I haven't followed every post.

Sent from my iPad

On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

Implied in using the “then", if…then…else would aways require “else" when using “then” similar to how “guard" requires “else”. This will help to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org> wrote:

1. I would really hate to explain to someone when if needs a then and when it doesn't. That's the sort of inconsistency that shouldn't be added lightly.

agreed definitely want to be careful with that. I think with braces meaning statements that differentiation can be made clear. I would certainly start with statements when describing, just as you usually don’t talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for replacing (A ? B : C) with some sort of (if A then B else C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify every outcome:

if cond {
  print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

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

masters3d · December 13, 2015, 7:45pm

Coming up with a special way to return from closures/blocks is being
discussed in the remove forEach thread. It may even need its own thread
since it would affect so much of the language.

···

On Sunday, December 13, 2015, Andrew Brown via swift-evolution < swift-evolution@swift.org> wrote:

I agree, but there seems to be a lot of support for statements as
expressions for some reason. That's not something I'd be keen to move
towards quickly but if we need to go there, how about a more general
solution.

Let's give every statement a builtin 'return' variable - I'll use _ in the
example below but I don't think it's really appropriate.

let x = if condition {
    _ = value1
  } else {
    _ = value2
  }

let width = if condition {_ = 1920} else {_ = 640}

With a default assumption that _ = void if the default, if no assignments
are used, we can ensure type checking and catch cases where not all paths
correctly assign to _

ABR.

On 13 Dec 2015, at 18:37, Marc Knaup via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Replacing constructs like

let x = condition ? 0 : 1

with

let x = if condition { 0 } else { 1 }

is very unlikely to make working with Swift any easier.

On Sun, Dec 13, 2015 at 7:18 PM, Dennis Lysenko < > dennis.s.lysenko@gmail.com > <javascript:_e(%7B%7D,'cvml','dennis.s.lysenko@gmail.com');>> wrote:

Just wanted to add, in regards to the argument of "why use 'then' rather
than keeping 'if condition { A } else { B }'?": besides my personal opinion
that inline braces look out-of-place, braces behave specially in xcode and
are notorious for screwing up indentation. For example, since swift was
released, multiple non-trailing closure arguments to a single function call
(e.g. MagicalRecord.saveWithBlock) are indented inconsistently, with the
second closure one indentation level higher than the first. More
generally/summarily, braces carry special indentation rules that do not
necessarily suit expressions.

On Sun, Dec 13, 2015, 12:17 PM Paul Ossenbruggen via swift-evolution < >> swift-evolution@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc@knaup.koeln >>> <javascript:_e(%7B%7D,'cvml','marc@knaup.koeln');>> wrote:

I also have no preference yet so I'll just throw in some thoughts.

** Existing Code **
The removal of the ternary operator would likely affect a lot of
existing code.
A quick search for " ? " (with spaces) over a large app of our team
yields 304 results.

Two simpler examples:

[
  "With Conditions": hasReport ? "yes" : "no",
  "With Image": hasImage ? "yes" : "no",
  "With Message": hasMessage ? "yes" : "no",
  "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
  "Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",
  "Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"
]

view1.alpha = editing ? 1 : 0
view2.alpha = editing ? 1 : 0
view3.alpha = editing ? 0 : 1
view4.alpha = editing ? 1 : 0

I am not sure using if…then…else would make this better to read &
understand or worse.

there seems to be a lot of people who dislike ternary operators. Other
languages also are similar in dumping ternary.

** Keyword then **
Making then a keyword would also cost us another word so that change
needs to be carefully considered.
In our large app I found just a single instance where then was used for
a variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }

Promises use the word then rather extensively: https://promisesaplus.com

Good point. Will think about it.

On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution < >>> swift-evolution@swift.org >>> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

I'm not quite sure how I feel about this specific proposal yet but in
general I do want to see conditional expressions and removal of the ternary
operator.

I would like to see "else if" included in whatever we adopt as the
final solution. Is there a reason this is omitted from this proposal? I
apologize if that was discussed in the thread. I haven't followed every
post.

Sent from my iPad

On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution < >>>> swift-evolution@swift.org >>>> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and
switch expressions based upon the discussions we had here. I have tried to
keep the scope of the changes as small as possible, only added one keyword
and kept things as similar to the existing language constructs as possible.
If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

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

Implied in using the “then", if…then…else would aways require “else"
when using “then” similar to how “guard" requires “else”. This will help
to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

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

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution < >>>> swift-evolution@swift.org >>>> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

1. I would really hate to explain to someone when *if* needs a *then*
and when it doesn't. That's the sort of inconsistency that shouldn't be
added lightly.

agreed definitely want to be careful with that. I think with braces
meaning statements that differentiation can be made clear. I would
certainly start with statements when describing, just as you usually don’t
talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for
replacing (A ? B : C) with some sort of (*if* A *then* B *else* C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be
usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify
every outcome:

if cond {
print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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 · December 13, 2015, 8:29pm

Definitely, agree that expr-statements would affect a lot in the language. I encourage people to look at the Swift grammar section for switch statements and then look at the ternary operator grammar. There is a clear distinction made between these two concepts in the existing language.

Expressions are mathematical concepts where there are inputs and one return value. Statement blocks are lists of commands without any such guaranteed output or side effects. Functional programming uses expressions to avoid much of the state and side effects that are common with imperative programming. It is very likely it would encourage a bunch of imperative programming side effect code based code, if statements become expressions. It will muddy the concept of expressions in people’s minds, trying to explain this to a student would be harder if the concepts are combined. I will say, I am not a huge fan of this idea, even if it is possible (although will try to keep an open mind).

Swift straddles the worlds of functional and imperative programming and a lot of functional programmers are drawn to the language because of it, keeping these concepts separate by having expressions and statements would help to keep the approaches separate in people’s minds. If you want to do the imperative approach use the statement, if you want to do the functional approach use the expressions. If they are combined then code that was written functionally might start getting imperative changes made by other developers on the team.

···

On Dec 13, 2015, at 11:45 AM, J. Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:

Coming up with a special way to return from closures/blocks is being discussed in the remove forEach thread. It may even need its own thread since it would affect so much of the language.

On Sunday, December 13, 2015, Andrew Brown via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I agree, but there seems to be a lot of support for statements as expressions for some reason. That's not something I'd be keen to move towards quickly but if we need to go there, how about a more general solution.

Let's give every statement a builtin 'return' variable - I'll use _ in the example below but I don't think it's really appropriate.

let x = if condition {
    _ = value1
  } else {
    _ = value2
  }

let width = if condition {_ = 1920} else {_ = 640}

With a default assumption that _ = void if the default, if no assignments are used, we can ensure type checking and catch cases where not all paths correctly assign to _

ABR.

On 13 Dec 2015, at 18:37, Marc Knaup via swift-evolution <swift-evolution@swift.org <>> wrote:

Replacing constructs like

let x = condition ? 0 : 1

with

let x = if condition { 0 } else { 1 }

is very unlikely to make working with Swift any easier.

On Sun, Dec 13, 2015 at 7:18 PM, Dennis Lysenko <dennis.s.lysenko@gmail.com <>> wrote:
Just wanted to add, in regards to the argument of "why use 'then' rather than keeping 'if condition { A } else { B }'?": besides my personal opinion that inline braces look out-of-place, braces behave specially in xcode and are notorious for screwing up indentation. For example, since swift was released, multiple non-trailing closure arguments to a single function call (e.g. MagicalRecord.saveWithBlock) are indented inconsistently, with the second closure one indentation level higher than the first. More generally/summarily, braces carry special indentation rules that do not necessarily suit expressions.

On Sun, Dec 13, 2015, 12:17 PM Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <>> wrote:

On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc@knaup.koeln <>> wrote:

I also have no preference yet so I'll just throw in some thoughts.

** Existing Code **
The removal of the ternary operator would likely affect a lot of existing code.
A quick search for " ? " (with spaces) over a large app of our team yields 304 results.

Two simpler examples:

[
    "With Conditions": hasReport ? "yes" : "no",
    "With Image": hasImage ? "yes" : "no",
    "With Message": hasMessage ? "yes" : "no",
    "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
    "Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",
    "Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"
]

view1.alpha = editing ? 1 : 0
view2.alpha = editing ? 1 : 0
view3.alpha = editing ? 0 : 1
view4.alpha = editing ? 1 : 0

I am not sure using if…then…else would make this better to read & understand or worse.

there seems to be a lot of people who dislike ternary operators. Other languages also are similar in dumping ternary.

** Keyword then **
Making then a keyword would also cost us another word so that change needs to be carefully considered.
In our large app I found just a single instance where then was used for a variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }
Promises use the word then rather extensively: https://promisesaplus.com <https://promisesaplus.com/>

Good point. Will think about it.

On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <>> wrote:
I'm not quite sure how I feel about this specific proposal yet but in general I do want to see conditional expressions and removal of the ternary operator.

I would like to see "else if" included in whatever we adopt as the final solution. Is there a reason this is omitted from this proposal? I apologize if that was discussed in the thread. I haven't followed every post.

Sent from my iPad

On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <>> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen@gmail.com <>> wrote:

Implied in using the “then", if…then…else would aways require “else" when using “then” similar to how “guard" requires “else”. This will help to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen@gmail.com <>> wrote:

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org <>> wrote:

1. I would really hate to explain to someone when if needs a then and when it doesn't. That's the sort of inconsistency that shouldn't be added lightly.

agreed definitely want to be careful with that. I think with braces meaning statements that differentiation can be made clear. I would certainly start with statements when describing, just as you usually don’t talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for replacing (A ? B : C) with some sort of (if A then B else C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify every outcome:

if cond {
  print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

_______________________________________________
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

possen · December 14, 2015, 8:19am

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

github.com

possen/swift-evolution/blob/master/0021.md

# Feature Replacement of Ternary Operator with "if" expression and Add "switch" expression 

* Proposal: [SE-NNNN](https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md)
* Author(s): Paul Ossenbruggen (https://github.com/swiftdev)
* Status: **Review**
* Review manager: TBD

## Introduction

The ternary operator has existed in C like languages for some time. For anyone reading it, who is not familiar with it, it is hard to understand what its purpose is, however it provides an important feature, which is creating an expression based upon a conditional expression result. 

Please see companion propopsal **Add Switch Expressions**

Swift-evolution thread: [ternary operator ?: suggestion ](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000810.html)

## Motivation

The main purpose is to replace the ternary operator with something that reads better. With this approach type inference can figure out what to initially conditionally assign a variable, with statements this is not possible. Statements can also consist of multiple statements, which is not possible with an expression. 

## Proposed solution

This file has been truncated. show original

Switch Expressions

So these proposals are based upon the idea that we should keep expressions and statements as separate concepts. If everyone decides that expressions should be made into statements or statements into expressions then both of these proposals should be declined, I do see that as a much bigger change and I am not sure it would be for the better. That is what this list is all about so maybe that, as was suggested by J. Cheyo, could be taken to a different thread.

I am thinking though, if making statements into expressions, is what is desired, that is going to push anything that supports what is in these proposals past Swift 3. These proposals are pretty limited in scope.

- Paul

···

On Dec 13, 2015, at 12:29 PM, Paul Ossenbruggen <possen@gmail.com> wrote:

Definitely, agree that expr-statements would affect a lot in the language. I encourage people to look at the Swift grammar section for switch statements and then look at the ternary operator grammar. There is a clear distinction made between these two concepts in the existing language.

Expressions are mathematical concepts where there are inputs and one return value. Statement blocks are lists of commands without any such guaranteed output or side effects. Functional programming uses expressions to avoid much of the state and side effects that are common with imperative programming. It is very likely it would encourage a bunch of imperative programming side effect code based code, if statements become expressions. It will muddy the concept of expressions in people’s minds, trying to explain this to a student would be harder if the concepts are combined. I will say, I am not a huge fan of this idea, even if it is possible (although will try to keep an open mind).

Swift straddles the worlds of functional and imperative programming and a lot of functional programmers are drawn to the language because of it, keeping these concepts separate by having expressions and statements would help to keep the approaches separate in people’s minds. If you want to do the imperative approach use the statement, if you want to do the functional approach use the expressions. If they are combined then code that was written functionally might start getting imperative changes made by other developers on the team.

Functional programming - Wikipedia

On Dec 13, 2015, at 11:45 AM, J. Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Coming up with a special way to return from closures/blocks is being discussed in the remove forEach thread. It may even need its own thread since it would affect so much of the language.

On Sunday, December 13, 2015, Andrew Brown via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I agree, but there seems to be a lot of support for statements as expressions for some reason. That's not something I'd be keen to move towards quickly but if we need to go there, how about a more general solution.

Let's give every statement a builtin 'return' variable - I'll use _ in the example below but I don't think it's really appropriate.

let x = if condition {
    _ = value1
  } else {
    _ = value2
  }

let width = if condition {_ = 1920} else {_ = 640}

With a default assumption that _ = void if the default, if no assignments are used, we can ensure type checking and catch cases where not all paths correctly assign to _

ABR.

On 13 Dec 2015, at 18:37, Marc Knaup via swift-evolution <swift-evolution@swift.org <>> wrote:

Replacing constructs like

let x = condition ? 0 : 1

with

let x = if condition { 0 } else { 1 }

is very unlikely to make working with Swift any easier.

On Sun, Dec 13, 2015 at 7:18 PM, Dennis Lysenko <dennis.s.lysenko@gmail.com <>> wrote:
Just wanted to add, in regards to the argument of "why use 'then' rather than keeping 'if condition { A } else { B }'?": besides my personal opinion that inline braces look out-of-place, braces behave specially in xcode and are notorious for screwing up indentation. For example, since swift was released, multiple non-trailing closure arguments to a single function call (e.g. MagicalRecord.saveWithBlock) are indented inconsistently, with the second closure one indentation level higher than the first. More generally/summarily, braces carry special indentation rules that do not necessarily suit expressions.

On Sun, Dec 13, 2015, 12:17 PM Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <>> wrote:

On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc@knaup.koeln <>> wrote:

I also have no preference yet so I'll just throw in some thoughts.

** Existing Code **
The removal of the ternary operator would likely affect a lot of existing code.
A quick search for " ? " (with spaces) over a large app of our team yields 304 results.

Two simpler examples:

[
    "With Conditions": hasReport ? "yes" : "no",
    "With Image": hasImage ? "yes" : "no",
    "With Message": hasMessage ? "yes" : "no",
    "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
    "Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",
    "Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"
]

view1.alpha = editing ? 1 : 0
view2.alpha = editing ? 1 : 0
view3.alpha = editing ? 0 : 1
view4.alpha = editing ? 1 : 0

I am not sure using if…then…else would make this better to read & understand or worse.

there seems to be a lot of people who dislike ternary operators. Other languages also are similar in dumping ternary.

** Keyword then **
Making then a keyword would also cost us another word so that change needs to be carefully considered.
In our large app I found just a single instance where then was used for a variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }
Promises use the word then rather extensively: https://promisesaplus.com <https://promisesaplus.com/>

Good point. Will think about it.

On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <>> wrote:
I'm not quite sure how I feel about this specific proposal yet but in general I do want to see conditional expressions and removal of the ternary operator.

I would like to see "else if" included in whatever we adopt as the final solution. Is there a reason this is omitted from this proposal? I apologize if that was discussed in the thread. I haven't followed every post.

Sent from my iPad

On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <>> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen@gmail.com <>> wrote:

Implied in using the “then", if…then…else would aways require “else" when using “then” similar to how “guard" requires “else”. This will help to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen@gmail.com <>> wrote:

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org <>> wrote:

1. I would really hate to explain to someone when if needs a then and when it doesn't. That's the sort of inconsistency that shouldn't be added lightly.

agreed definitely want to be careful with that. I think with braces meaning statements that differentiation can be made clear. I would certainly start with statements when describing, just as you usually don’t talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for replacing (A ? B : C) with some sort of (if A then B else C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify every outcome:

if cond {
  print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

_______________________________________________
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

owensd · December 14, 2015, 6:38pm

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

···

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

Switch Expressions
Sign in to GitHub · GitHub

So these proposals are based upon the idea that we should keep expressions and statements as separate concepts. If everyone decides that expressions should be made into statements or statements into expressions then both of these proposals should be declined, I do see that as a much bigger change and I am not sure it would be for the better. That is what this list is all about so maybe that, as was suggested by J. Cheyo, could be taken to a different thread.

I am thinking though, if making statements into expressions, is what is desired, that is going to push anything that supports what is in these proposals past Swift 3. These proposals are pretty limited in scope.

- Paul

On Dec 13, 2015, at 12:29 PM, Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>> wrote:

Definitely, agree that expr-statements would affect a lot in the language. I encourage people to look at the Swift grammar section for switch statements and then look at the ternary operator grammar. There is a clear distinction made between these two concepts in the existing language.

Expressions are mathematical concepts where there are inputs and one return value. Statement blocks are lists of commands without any such guaranteed output or side effects. Functional programming uses expressions to avoid much of the state and side effects that are common with imperative programming. It is very likely it would encourage a bunch of imperative programming side effect code based code, if statements become expressions. It will muddy the concept of expressions in people’s minds, trying to explain this to a student would be harder if the concepts are combined. I will say, I am not a huge fan of this idea, even if it is possible (although will try to keep an open mind).

Swift straddles the worlds of functional and imperative programming and a lot of functional programmers are drawn to the language because of it, keeping these concepts separate by having expressions and statements would help to keep the approaches separate in people’s minds. If you want to do the imperative approach use the statement, if you want to do the functional approach use the expressions. If they are combined then code that was written functionally might start getting imperative changes made by other developers on the team.

Functional programming - Wikipedia

On Dec 13, 2015, at 11:45 AM, J. Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Coming up with a special way to return from closures/blocks is being discussed in the remove forEach thread. It may even need its own thread since it would affect so much of the language.

On Sunday, December 13, 2015, Andrew Brown via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I agree, but there seems to be a lot of support for statements as expressions for some reason. That's not something I'd be keen to move towards quickly but if we need to go there, how about a more general solution.

Let's give every statement a builtin 'return' variable - I'll use _ in the example below but I don't think it's really appropriate.

let x = if condition {
    _ = value1
  } else {
    _ = value2
  }

let width = if condition {_ = 1920} else {_ = 640}

With a default assumption that _ = void if the default, if no assignments are used, we can ensure type checking and catch cases where not all paths correctly assign to _

ABR.

On 13 Dec 2015, at 18:37, Marc Knaup via swift-evolution <swift-evolution@swift.org <>> wrote:

Replacing constructs like

let x = condition ? 0 : 1

with

let x = if condition { 0 } else { 1 }

is very unlikely to make working with Swift any easier.

On Sun, Dec 13, 2015 at 7:18 PM, Dennis Lysenko <dennis.s.lysenko@gmail.com <>> wrote:
Just wanted to add, in regards to the argument of "why use 'then' rather than keeping 'if condition { A } else { B }'?": besides my personal opinion that inline braces look out-of-place, braces behave specially in xcode and are notorious for screwing up indentation. For example, since swift was released, multiple non-trailing closure arguments to a single function call (e.g. MagicalRecord.saveWithBlock) are indented inconsistently, with the second closure one indentation level higher than the first. More generally/summarily, braces carry special indentation rules that do not necessarily suit expressions.

On Sun, Dec 13, 2015, 12:17 PM Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <>> wrote:

On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc@knaup.koeln <>> wrote:

I also have no preference yet so I'll just throw in some thoughts.

** Existing Code **
The removal of the ternary operator would likely affect a lot of existing code.
A quick search for " ? " (with spaces) over a large app of our team yields 304 results.

Two simpler examples:

[
    "With Conditions": hasReport ? "yes" : "no",
    "With Image": hasImage ? "yes" : "no",
    "With Message": hasMessage ? "yes" : "no",
    "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
    "Shared in Facebook Group": sharedOnFacebookGroup ? "yes" : "no",
    "Shared on Facebook Page": sharedOnFacebookPage ? "yes" : "no"
]

view1.alpha = editing ? 1 : 0
view2.alpha = editing ? 1 : 0
view3.alpha = editing ? 0 : 1
view4.alpha = editing ? 1 : 0

I am not sure using if…then…else would make this better to read & understand or worse.

there seems to be a lot of people who dislike ternary operators. Other languages also are similar in dumping ternary.

** Keyword then **
Making then a keyword would also cost us another word so that change needs to be carefully considered.
In our large app I found just a single instance where then was used for a variable's name:

func reloadConfigurationAndThen(then: () -> Void) { … }
Promises use the word then rather extensively: https://promisesaplus.com <https://promisesaplus.com/>

Good point. Will think about it.

On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <>> wrote:
I'm not quite sure how I feel about this specific proposal yet but in general I do want to see conditional expressions and removal of the ternary operator.

I would like to see "else if" included in whatever we adopt as the final solution. Is there a reason this is omitted from this proposal? I apologize if that was discussed in the thread. I haven't followed every post.

Sent from my iPad

On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <>> wrote:

Hello All,

Been sick in bed all day, but decided to try to be productive…

I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,

https://github.com/possen/swift-evolution/blob/master/0020.md

Thanks,
- Paul

On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen@gmail.com <>> wrote:

Implied in using the “then", if…then…else would aways require “else" when using “then” similar to how “guard" requires “else”. This will help to make the difference between statements and expressions clear.

let x = If cond then X else Y

is the full form, where “else" can not be omitted.

On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen@gmail.com <>> wrote:

On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org <>> wrote:

1. I would really hate to explain to someone when if needs a then and when it doesn't. That's the sort of inconsistency that shouldn't be added lightly.

agreed definitely want to be careful with that. I think with braces meaning statements that differentiation can be made clear. I would certainly start with statements when describing, just as you usually don’t talk about the ternary operator until later.

3. If we can somehow solve all of this, I think I'll be +1 for replacing (A ? B : C) with some sort of (if A then B else C).

Yes that would be great.

4. Generally, I wonder how hard would it be for all statements to be usable as expressions? Why didn't Swift go that way from the start?

The biggest problem statement is you don’t need to exhaustively specify every outcome:

if cond {
  print(“hello”)
}

whereas in an expression you have to specify what happens in the else.

let say = if cond then “hello” else “goodbye"

unless you go seriously off the deep end:

let say = if cond then “hello”

“say" then becomes an optional, *shudder*

_______________________________________________
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

_______________________________________________
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

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

Chris_Lattner1 · December 14, 2015, 6:57pm

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

···

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

Nick_Shelley · December 15, 2015, 12:50am

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