ternary operator ?: suggestion


(Chéyo Jiménez) #1

Would you consider replacing the C style ?: ternary operator to something
that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.

let result = !condition ? 1 : 2

Some alternatives:

Haskel

if predicate then expr1 else expr2

Python

result = x if a > b else y

The advantage of not using the question mark is that the language will be
more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066


(Dan Appel) #2

I agree that ternary can make code unreadable, especially so with the ‘?’.
I personally like the Haskel option the most, but it introduces a new
keyword ‘then’, which isn’t great either. Python’s "y if x else z" is
therefore, in my opinion, the best alternative.

Also, I found it interesting how split the Rust community was about
removing the ternary operator.

···


Dan Appel

On Thu, Dec 3, 2015 at 7:58 PM J. Cheyo Jimenez <cheyo@masters3d.com> wrote:

Would you consider replacing the C style ?: ternary operator to something
that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.

let result = !condition ? 1 : 2

Some alternatives:

Haskel

if predicate then expr1 else expr2

Python

result = x if a > b else y

The advantage of not using the question mark is that the language will be
more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Sean Heber) #3

I agree that using ? for ternary feels.. uncomfortable in Swift. I wouldn't mind seeing Python-style or just eliminating it entirely in favor of simplicity.

l8r
Sean

···

On Dec 3, 2015, at 10:48 PM, Dan Appel <dan.appel00@gmail.com> wrote:

I agree that ternary can make code unreadable, especially so with the ‘?’. I personally like the Haskel option the most, but it introduces a new keyword ‘then’, which isn’t great either. Python’s "y if x else z" is therefore, in my opinion, the best alternative.

Also, I found it interesting how split the Rust community was about removing the ternary operator.


Dan Appel

On Thu, Dec 3, 2015 at 7:58 PM J. Cheyo Jimenez <cheyo@masters3d.com> wrote:
Would you consider replacing the C style ?: ternary operator to something that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.
let result = !condition ? 1 : 2

Some alternatives:

Haskel
if predicate then expr1 else expr2
Python
result = x if a > b else y
The advantage of not using the question mark is that the language will be more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066
_______________________________________________
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


(David Hart) #4

I also tend to agree but I don't like the ordering in the Python version and would rather see the introduction of the then keyword

···

On 04 Dec 2015, at 06:08, Sean Heber <sean@fifthace.com> wrote:

I agree that using ? for ternary feels.. uncomfortable in Swift. I wouldn't mind seeing Python-style or just eliminating it entirely in favor of simplicity.

l8r
Sean

On Dec 3, 2015, at 10:48 PM, Dan Appel <dan.appel00@gmail.com> wrote:

I agree that ternary can make code unreadable, especially so with the ‘?’. I personally like the Haskel option the most, but it introduces a new keyword ‘then’, which isn’t great either. Python’s "y if x else z" is therefore, in my opinion, the best alternative.

Also, I found it interesting how split the Rust community was about removing the ternary operator.


Dan Appel

On Thu, Dec 3, 2015 at 7:58 PM J. Cheyo Jimenez <cheyo@masters3d.com> wrote:
Would you consider replacing the C style ?: ternary operator to something that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.
let result = !condition ? 1 : 2

Some alternatives:

Haskel
if predicate then expr1 else expr2
Python
result = x if a > b else y
The advantage of not using the question mark is that the language will be more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066
_______________________________________________
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


(David Waite) #5

Of course one could just drop it as a grammatical language feature and turn it a standard library feature of some form, e.g.:

@warn_unused_result
func when<T>(@autoclosure expr: ()->Bool, @autoclosure value: ()->T, @autoclosure otherwise: ()->T) -> T {
  if expr() {
    return value()
  }
  else {
    return otherwise()
  }
}

var a = when(1 + 1 == 2, value: "works", otherwise: "fails")

print(a) // => “works"

-DW

···

On Dec 4, 2015, at 12:26 AM, David Hart <david@hartbit.com> wrote:

I also tend to agree but I don't like the ordering in the Python version and would rather see the introduction of the then keyword

On 04 Dec 2015, at 06:08, Sean Heber <sean@fifthace.com <mailto:sean@fifthace.com>> wrote:

I agree that using ? for ternary feels.. uncomfortable in Swift. I wouldn't mind seeing Python-style or just eliminating it entirely in favor of simplicity.

l8r
Sean

On Dec 3, 2015, at 10:48 PM, Dan Appel <dan.appel00@gmail.com <mailto:dan.appel00@gmail.com>> wrote:

I agree that ternary can make code unreadable, especially so with the ‘?’. I personally like the Haskel option the most, but it introduces a new keyword ‘then’, which isn’t great either. Python’s "y if x else z" is therefore, in my opinion, the best alternative.

Also, I found it interesting how split the Rust community was about removing the ternary operator.


Dan Appel

On Thu, Dec 3, 2015 at 7:58 PM J. Cheyo Jimenez <cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:
Would you consider replacing the C style ?: ternary operator to something that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.
let result = !condition ? 1 : 2

Some alternatives:

Haskel
if predicate then expr1 else expr2
Python
result = x if a > b else y
The advantage of not using the question mark is that the language will be more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066 _______________________________________________
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

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


(David Owens II) #6

There’s no need for the “then" keyword if you just allow if-expressions as well.

let result = if condition { 1 } else { 2 }

Or more verbosely:

let result =
    if condition {
        return 1
    }
    else {
        return 2
    }

The same could be for switch statements as well.

let result = switch item {
    case foo: 1
    case bar: 2
}

The above assume implicit returns on single-line statements on the condition/case branches.

-David

···

On Dec 3, 2015, at 11:26 PM, David Hart <david@hartbit.com> wrote:

I also tend to agree but I don't like the ordering in the Python version and would rather see the introduction of the then keyword

On 04 Dec 2015, at 06:08, Sean Heber <sean@fifthace.com <mailto:sean@fifthace.com>> wrote:

I agree that using ? for ternary feels.. uncomfortable in Swift. I wouldn't mind seeing Python-style or just eliminating it entirely in favor of simplicity.

l8r
Sean

On Dec 3, 2015, at 10:48 PM, Dan Appel <dan.appel00@gmail.com <mailto:dan.appel00@gmail.com>> wrote:

I agree that ternary can make code unreadable, especially so with the ‘?’. I personally like the Haskel option the most, but it introduces a new keyword ‘then’, which isn’t great either. Python’s "y if x else z" is therefore, in my opinion, the best alternative.

Also, I found it interesting how split the Rust community was about removing the ternary operator.


Dan Appel

On Thu, Dec 3, 2015 at 7:58 PM J. Cheyo Jimenez <cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:
Would you consider replacing the C style ?: ternary operator to something that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.
let result = !condition ? 1 : 2

Some alternatives:

Haskel
if predicate then expr1 else expr2
Python
result = x if a > b else y
The advantage of not using the question mark is that the language will be more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066 _______________________________________________
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

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


(Sean Heber) #7

Could alternatively could take a page from Smalltalk:

   extension Bool {
      func ifTrue<T>(@autoclosure isTrue: () -> T, @autoclosure otherwise isFalse: () -> T) -> T {
         if self {
            return isTrue()
         } else {
            return isFalse()
         }
      }
   }

:slight_smile:

l8r
Sean

···

On Dec 4, 2015, at 1:40 AM, David Waite <david@alkaline-solutions.com> wrote:

Of course one could just drop it as a grammatical language feature and turn it a standard library feature of some form, e.g.:

@warn_unused_result
func when<T>(@autoclosure expr: ()->Bool, @autoclosure value: ()->T, @autoclosure otherwise: ()->T) -> T {
  if expr() {
    return value()
  }
  else {
    return otherwise()
  }
}

var a = when(1 + 1 == 2, value: "works", otherwise: "fails")

print(a) // => “works"

-DW

On Dec 4, 2015, at 12:26 AM, David Hart <david@hartbit.com> wrote:

I also tend to agree but I don't like the ordering in the Python version and would rather see the introduction of the then keyword

On 04 Dec 2015, at 06:08, Sean Heber <sean@fifthace.com> wrote:

I agree that using ? for ternary feels.. uncomfortable in Swift. I wouldn't mind seeing Python-style or just eliminating it entirely in favor of simplicity.

l8r
Sean

On Dec 3, 2015, at 10:48 PM, Dan Appel <dan.appel00@gmail.com> wrote:

I agree that ternary can make code unreadable, especially so with the ‘?’. I personally like the Haskel option the most, but it introduces a new keyword ‘then’, which isn’t great either. Python’s "y if x else z" is therefore, in my opinion, the best alternative.

Also, I found it interesting how split the Rust community was about removing the ternary operator.


Dan Appel

On Thu, Dec 3, 2015 at 7:58 PM J. Cheyo Jimenez <cheyo@masters3d.com> wrote:
Would you consider replacing the C style ?: ternary operator to something that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.
let result = !condition ? 1 : 2

Some alternatives:

Haskel
if predicate then expr1 else expr2
Python
result = x if a > b else y
The advantage of not using the question mark is that the language will be more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066
_______________________________________________
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


(Adrian Kashivskyy) #8

-1 on Bool extension, this should exist as a free function. Reason?

(1 + 1 == 2).ifTrue("foo", otherwise: "bar")

This: 1. doesn't look well; 2. is not clear and understandable; 3. doesn't allow condition to be a closure.

Pozdrawiam – Regards,
Adrian Kashivskyy

···

Wiadomość napisana przez Sean Heber <sean@fifthace.com> w dniu 04.12.2015, o godz. 16:54:

Could alternatively could take a page from Smalltalk:

  extension Bool {
     func ifTrue<T>(@autoclosure isTrue: () -> T, @autoclosure otherwise isFalse: () -> T) -> T {
        if self {
           return isTrue()
        } else {
           return isFalse()
        }
     }
  }

:slight_smile:

l8r
Sean

On Dec 4, 2015, at 1:40 AM, David Waite <david@alkaline-solutions.com> wrote:

Of course one could just drop it as a grammatical language feature and turn it a standard library feature of some form, e.g.:

@warn_unused_result
func when<T>(@autoclosure expr: ()->Bool, @autoclosure value: ()->T, @autoclosure otherwise: ()->T) -> T {
if expr() {
   return value()
}
else {
   return otherwise()
}
}

var a = when(1 + 1 == 2, value: "works", otherwise: "fails")

print(a) // => “works"

-DW

On Dec 4, 2015, at 12:26 AM, David Hart <david@hartbit.com> wrote:

I also tend to agree but I don't like the ordering in the Python version and would rather see the introduction of the then keyword

On 04 Dec 2015, at 06:08, Sean Heber <sean@fifthace.com> wrote:

I agree that using ? for ternary feels.. uncomfortable in Swift. I wouldn't mind seeing Python-style or just eliminating it entirely in favor of simplicity.

l8r
Sean

On Dec 3, 2015, at 10:48 PM, Dan Appel <dan.appel00@gmail.com> wrote:

I agree that ternary can make code unreadable, especially so with the ‘?’. I personally like the Haskel option the most, but it introduces a new keyword ‘then’, which isn’t great either. Python’s "y if x else z" is therefore, in my opinion, the best alternative.

Also, I found it interesting how split the Rust community was about removing the ternary operator.


Dan Appel

On Thu, Dec 3, 2015 at 7:58 PM J. Cheyo Jimenez <cheyo@masters3d.com> wrote:
Would you consider replacing the C style ?: ternary operator to something that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.
let result = !condition ? 1 : 2

Some alternatives:

Haskel
if predicate then expr1 else expr2
Python
result = x if a > b else y
The advantage of not using the question mark is that the language will be more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066
_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #9

Best proposition since, but still more verbose than the ternary operator.

···

On 04 Dec 2015, at 18:27, David Owens II <david@owensd.io> wrote:

There’s no need for the “then" keyword if you just allow if-expressions as well.

let result = if condition { 1 } else { 2 }

Or more verbosely:

let result =
    if condition {
        return 1
    }
    else {
        return 2
    }

The same could be for switch statements as well.

let result = switch item {
    case foo: 1
    case bar: 2
}

The above assume implicit returns on single-line statements on the condition/case branches.

-David

On Dec 3, 2015, at 11:26 PM, David Hart <david@hartbit.com> wrote:

I also tend to agree but I don't like the ordering in the Python version and would rather see the introduction of the then keyword

On 04 Dec 2015, at 06:08, Sean Heber <sean@fifthace.com> wrote:

I agree that using ? for ternary feels.. uncomfortable in Swift. I wouldn't mind seeing Python-style or just eliminating it entirely in favor of simplicity.

l8r
Sean

On Dec 3, 2015, at 10:48 PM, Dan Appel <dan.appel00@gmail.com> wrote:

I agree that ternary can make code unreadable, especially so with the ‘?’. I personally like the Haskel option the most, but it introduces a new keyword ‘then’, which isn’t great either. Python’s "y if x else z" is therefore, in my opinion, the best alternative.

Also, I found it interesting how split the Rust community was about removing the ternary operator.


Dan Appel

On Thu, Dec 3, 2015 at 7:58 PM J. Cheyo Jimenez <cheyo@masters3d.com> wrote:
Would you consider replacing the C style ?: ternary operator to something that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.
let result = !condition ? 1 : 2

Some alternatives:

Haskel
if predicate then expr1 else expr2
Python
result = x if a > b else y
The advantage of not using the question mark is that the language will be more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066
_______________________________________________
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


(Chéyo Jiménez) #10

The motive is to desist the use of the question mark outside of the swift
optional context.
I like the rust style if-expression as an alternative.
Imo consistency and readability is a little more important than brevity.

···

On Friday, December 4, 2015, David Hart <david@hartbit.com> wrote:

Best proposition since, but still more verbose than the ternary operator.

On 04 Dec 2015, at 18:27, David Owens II <david@owensd.io > <javascript:_e(%7B%7D,'cvml','david@owensd.io');>> wrote:

There’s no need for the “then" keyword if you just allow if-expressions as
well.

let result = if condition { 1 } else { 2 }

Or more verbosely:

let result =
    if condition {
        return 1
    }
    else {
        return 2
    }

The same could be for switch statements as well.

let result = switch item {
    case foo: 1
    case bar: 2
}

The above assume implicit returns on single-line statements on the
condition/case branches.

-David

On Dec 3, 2015, at 11:26 PM, David Hart <david@hartbit.com > <javascript:_e(%7B%7D,'cvml','david@hartbit.com');>> wrote:

I also tend to agree but I don't like the ordering in the Python version
and would rather see the introduction of the then keyword

On 04 Dec 2015, at 06:08, Sean Heber <sean@fifthace.com > <javascript:_e(%7B%7D,'cvml','sean@fifthace.com');>> wrote:

I agree that using ? for ternary feels.. uncomfortable in Swift. I
wouldn't mind seeing Python-style or just eliminating it entirely in favor
of simplicity.

l8r
Sean

On Dec 3, 2015, at 10:48 PM, Dan Appel <dan.appel00@gmail.com > <javascript:_e(%7B%7D,'cvml','dan.appel00@gmail.com');>> wrote:

I agree that ternary can make code unreadable, especially so with the ‘?’.
I personally like the Haskel option the most, but it introduces a new
keyword ‘then’, which isn’t great either. Python’s "y if x else z" is
therefore, in my opinion, the best alternative.

Also, I found it interesting how split the Rust community was about
removing the ternary operator.


Dan Appel

On Thu, Dec 3, 2015 at 7:58 PM J. Cheyo Jimenez <cheyo@masters3d.com > <javascript:_e(%7B%7D,'cvml','cheyo@masters3d.com');>> wrote:

Would you consider replacing the C style ?: ternary operator to something
that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.

let result = !condition ? 1 : 2

Some alternatives:

Haskel

if predicate then expr1 else expr2

Python

result = x if a > b else y

The advantage of not using the question mark is that the language will be
more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066
_______________________________________________
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


(Chéyo Jiménez) #11

I'd like some feedback from the core team to see if eliminating the ternary
operator and replacing it with if-else is even proposal worthy.

Some interesting code in the standard library that uses the ternary
operator quite a bit.

https://gist.github.com/masters3d/7b0c6f3653368afe4357

···

On Fri, Dec 4, 2015 at 12:50 PM, J. Cheyo Jimenez <cheyo@masters3d.com> wrote:

The motive is to desist the use of the question mark outside of the swift
optional context.
I like the rust style if-expression as an alternative.
Imo consistency and readability is a little more important than brevity.

On Friday, December 4, 2015, David Hart <david@hartbit.com> wrote:

Best proposition since, but still more verbose than the ternary operator.

On 04 Dec 2015, at 18:27, David Owens II <david@owensd.io> wrote:

There’s no need for the “then" keyword if you just allow if-expressions
as well.

let result = if condition { 1 } else { 2 }

Or more verbosely:

let result =
    if condition {
        return 1
    }
    else {
        return 2
    }

The same could be for switch statements as well.

let result = switch item {
    case foo: 1
    case bar: 2
}

The above assume implicit returns on single-line statements on the
condition/case branches.

-David

On Dec 3, 2015, at 11:26 PM, David Hart <david@hartbit.com> wrote:

I also tend to agree but I don't like the ordering in the Python version
and would rather see the introduction of the then keyword

On 04 Dec 2015, at 06:08, Sean Heber <sean@fifthace.com> wrote:

I agree that using ? for ternary feels.. uncomfortable in Swift. I
wouldn't mind seeing Python-style or just eliminating it entirely in favor
of simplicity.

l8r
Sean

On Dec 3, 2015, at 10:48 PM, Dan Appel <dan.appel00@gmail.com> wrote:

I agree that ternary can make code unreadable, especially so with the
‘?’. I personally like the Haskel option the most, but it introduces a new
keyword ‘then’, which isn’t great either. Python’s "y if x else z" is
therefore, in my opinion, the best alternative.

Also, I found it interesting how split the Rust community was about
removing the ternary operator.


Dan Appel

On Thu, Dec 3, 2015 at 7:58 PM J. Cheyo Jimenez <cheyo@masters3d.com> >> wrote:

Would you consider replacing the C style ?: ternary operator to
something that does not use the question mark and colon ?

The use of "?" can be confusing when speed reading code with optionals.

Consider this code as somebody learning swift as their first language.

let result = !condition ? 1 : 2

Some alternatives:

Haskel

if predicate then expr1 else expr2

Python

result = x if a > b else y

The advantage of not using the question mark is that the language will
be more consistency on the use of "?" to mean only optionals.

References:
https://devforums.apple.com/message/1020139#1020139
https://github.com/rust-lang/rust/issues/1698#issuecomment-3705066
_______________________________________________
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


(Chris Lattner) #12

FWIW, I have no love for the ternary operator (it is totally "bizarre C magic”), but it does solve a problem that Swift currently otherwise has no solution for.

If you’re interested in pursuing this, then the right path forward is to build a holistic proposal to turn statements (like if and switch) into expressions. This is subtle and requires thought, but is widely desired and if someone were interested in driving the design and implementation, then I’d be interested to see it happen.

-Chris

···

On Dec 4, 2015, at 11:43 AM, J. Cheyo Jimenez <cheyo@masters3d.com> wrote:

I'd like some feedback from the core team to see if eliminating the ternary operator and replacing it with if-else is even proposal worthy.

Some interesting code in the standard library that uses the ternary operator quite a bit.

https://gist.github.com/masters3d/7b0c6f3653368afe4357


(Jon Hull) #13

I think I have a solution for the ternary part, but I am not sure I fully understand what is being asked for in the case of switch. Could someone clarify?

There is another thread which goes into the idea a little more, but the basic idea is that we replace the ternary operator with ‘if?'

let x = value if? condition

If condition is true, then x is value… otherwise it is nil. You can combine with the nil-coalescing operator to get else and else if style behavior:

let x = valueA if? conditionA ?? valueB if? conditionB ?? valueC

Thanks,
Jon

···

On Dec 5, 2015, at 9:09 AM, Chris Lattner <clattner@apple.com> wrote:

On Dec 4, 2015, at 11:43 AM, J. Cheyo Jimenez <cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:

I'd like some feedback from the core team to see if eliminating the ternary operator and replacing it with if-else is even proposal worthy.

Some interesting code in the standard library that uses the ternary operator quite a bit.

https://gist.github.com/masters3d/7b0c6f3653368afe4357

FWIW, I have no love for the ternary operator (it is totally "bizarre C magic”), but it does solve a problem that Swift currently otherwise has no solution for.

If you’re interested in pursuing this, then the right path forward is to build a holistic proposal to turn statements (like if and switch) into expressions. This is subtle and requires thought, but is widely desired and if someone were interested in driving the design and implementation, then I’d be interested to see it happen.

-Chris

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


(David Hart) #14

This is subtle and requires thought

What do you envision as the pitfalls of the design thinking behind if/switch expressions? I’m not a compiler programmer, but a prog-lang enthusiast. I wouldn’t mind a little nudge in the right direction.

David.

···

On 05 Dec 2015, at 18:09, Chris Lattner <clattner@apple.com> wrote:

On Dec 4, 2015, at 11:43 AM, J. Cheyo Jimenez <cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:

I'd like some feedback from the core team to see if eliminating the ternary operator and replacing it with if-else is even proposal worthy.

Some interesting code in the standard library that uses the ternary operator quite a bit.

https://gist.github.com/masters3d/7b0c6f3653368afe4357

FWIW, I have no love for the ternary operator (it is totally "bizarre C magic”), but it does solve a problem that Swift currently otherwise has no solution for.

If you’re interested in pursuing this, then the right path forward is to build a holistic proposal to turn statements (like if and switch) into expressions. This is subtle and requires thought, but is widely desired and if someone were interested in driving the design and implementation, then I’d be interested to see it happen.

-Chris


(Alex Lew) #15

I believe the idea with switch is that it would be nice to be able to do something like

// make sure we have different favorite colors
let myFavoriteColor =
  switch yourFavoriteColor {
    case .Red:
    return .Blue
    case .Green:
    return .Red
    case .Blue:
    return .Green
  }

This is useful and exists in other functional languages. For example, ML has “case … of …”, Coq has “match…with…end”, etc.

This is similar to what you are proposing with if:

let x = if (condition) { return value } else { return otherValue }

because in both cases you are taking what is currently a statement in Swift and enabling it to be used as an expression. (Of course, the syntax would ideally be nicer — maybe we limit each case’s body to be a single expression and get rid of the return keyword, for example.) Worth noting that in both cases, the type-checker needs to ensure that the type of each result is the same.

The semantics of what you’re now proposing — an if? binary operator that evaluates a condition then evaluates to either nil (if false) or some value (if true) — is slightly different. I’m not sure I love it — the general use case would be something like “if __ then ___ else ___” and I don’t think it reads that way. It also doesn’t allow for pattern matching (though to be fair, neither does the ternary operator) — it could be cool to see something like

let greeting = “Hello, \(name),” if let name = optionalName else “To Whom It May Concern:”

-Alex

···

On Dec 5, 2015, at 6:28 PM, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:

I think I have a solution for the ternary part, but I am not sure I fully understand what is being asked for in the case of switch. Could someone clarify?

There is another thread which goes into the idea a little more, but the basic idea is that we replace the ternary operator with ‘if?'

let x = value if? condition

If condition is true, then x is value… otherwise it is nil. You can combine with the nil-coalescing operator to get else and else if style behavior:

let x = valueA if? conditionA ?? valueB if? conditionB ?? valueC

Thanks,
Jon

On Dec 5, 2015, at 9:09 AM, Chris Lattner < clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Dec 4, 2015, at 11:43 AM, J. Cheyo Jimenez < cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:

I'd like some feedback from the core team to see if eliminating the ternary operator and replacing it with if-else is even proposal worthy.

Some interesting code in the standard library that uses the ternary operator quite a bit.

https://gist.github.com/masters3d/7b0c6f3653368afe4357

FWIW, I have no love for the ternary operator (it is totally "bizarre C magic”), but it does solve a problem that Swift currently otherwise has no solution for.

If you’re interested in pursuing this, then the right path forward is to build a holistic proposal to turn statements (like if and switch) into expressions. This is subtle and requires thought, but is widely desired and if someone were interested in driving the design and implementation, then I’d be interested to see it happen.

-Chris

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

Untracked with Trackbuster <https://trackbuster.com/?sig>_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Alex Lew) #16

I believe the idea with switch is that it would be nice to be able to do
something like

// make sure we have different favorite colors
let myFavoriteColor =
switch yourFavoriteColor {
case .Red:
return .Blue
case .Green:
return .Red
case .Blue:
return .Green
}

This is useful and exists in other functional languages. For example, ML
has “case … of …”, Coq has “match…with…end”, etc.

This is similar to what you are proposing with if:

let x = if (condition) { return value } else { return otherValue }

because in both cases you are taking what is currently a statement in Swift
and enabling it to be used as an expression. (Of course, the syntax would
ideally be nicer — maybe we limit each case’s body to be a single
expression and get rid of the return keyword, for example.) Worth noting
that in both cases, the type-checker needs to ensure that the type of each
result is the same.

The semantics of what you’re now proposing — an if? binary operator that
evaluates a condition then evaluates to either nil (if false) or some value
(if true) — is slightly different. I’m not sure I love it — the general use
case would be something like “if __ then ___ else ___” and I don’t think it
reads that way. It also doesn’t allow for pattern matching (though to be
fair, neither does the ternary operator) — it could be cool to see
something like

let greeting = “Hello, \(name),” if let name = optionalName else “To Whom
It May Concern:”

-Alex

···

On Sat, Dec 5, 2015 at 6:28 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote:

I think I have a solution for the ternary part, but I am not sure I fully
understand what is being asked for in the case of switch. Could someone
clarify?

There is another thread which goes into the idea a little more, but the
basic idea is that we replace the ternary operator with ‘if?'

let x = value if? condition

If condition is true, then x is value… otherwise it is nil. You can
combine with the nil-coalescing operator to get else and else if style
behavior:

let x = valueA if? conditionA ?? valueB if? conditionB ?? valueC

Thanks,
Jon

On Dec 5, 2015, at 9:09 AM, Chris Lattner < clattner@apple.com> wrote:

On Dec 4, 2015, at 11:43 AM, J. Cheyo Jimenez < cheyo@masters3d.com> > wrote:

I'd like some feedback from the core team to see if eliminating
the ternary operator and replacing it with if-else is even proposal
worthy.

Some interesting code in the standard library that uses the ternary
operator quite a bit.

https://gist.github.com/masters3d/7b0c6f3653368afe4357

FWIW, I have no love for the ternary operator (it is totally "bizarre C
magic”), but it does solve a problem that Swift currently otherwise has no
solution for.

If you’re interested in pursuing this, then the right path forward is to
build a holistic proposal to turn statements (like if and switch) into
expressions. This is subtle and requires thought, but is widely desired
and if someone were interested in driving the design and implementation,
then I’d be interested to see it happen.

-Chris

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

Untracked with Trackbuster <https://trackbuster.com/?sig>

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


(Chris Lattner) #17

I responded with some concerns and thoughts on the "Control Flow Expressions” thread.

-Chris

···

On Dec 5, 2015, at 11:40 AM, David Hart <david@hartbit.com> wrote:

This is subtle and requires thought

What do you envision as the pitfalls of the design thinking behind if/switch expressions? I’m not a compiler programmer, but a prog-lang enthusiast. I wouldn’t mind a little nudge in the right direction.


(Ole Begemann) #18

This is subtle and requires thought

What do you envision as the pitfalls of the design thinking behind if/switch expressions? I’m not a compiler programmer, but a prog-lang enthusiast. I wouldn’t mind a little nudge in the right direction.

One thing that comes to mind is that if "if" is an expression, every if needs an else branch. This makes it harder to use if to conditionally perform side effects. For example, this is currently valid:

func doSomething() { ... }

if condition {
    doSomething()
}

Should this be allowed? You could argue that this should work because (a) the expression result is unused and (b) the return type of doSomething is Void, so the compiler could conceivably implicitly construct an else branch that returns (). But it would be inconsistent with other expressions. Disallowing this style could make writing typical "imperative" code harder.

– Ole


(Adam Lickel) #19

In that situation, the if statement could return a Void? where the else implicitly returns nil

···

On Dec 5, 2015, at 3:12 PM, Ole Begemann via swift-evolution <swift-evolution@swift.org> wrote:

This is subtle and requires thought

What do you envision as the pitfalls of the design thinking behind if/switch expressions? I’m not a compiler programmer, but a prog-lang enthusiast. I wouldn’t mind a little nudge in the right direction.

One thing that comes to mind is that if "if" is an expression, every if needs an else branch. This makes it harder to use if to conditionally perform side effects. For example, this is currently valid:

func doSomething() { ... }

if condition {
   doSomething()
}

Should this be allowed? You could argue that this should work because (a) the expression result is unused and (b) the return type of doSomething is Void, so the compiler could conceivably implicitly construct an else branch that returns (). But it would be inconsistent with other expressions. Disallowing this style could make writing typical "imperative" code harder.

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


(Ole Begemann) #20

Yeah, returning an optional is a good idea.

···

On 06 Dec 2015, at 01:22, Adam C. Lickel <adam@lickel.com> wrote:

In that situation, the if statement could return a Void? where the else implicitly returns nil

On Dec 5, 2015, at 3:12 PM, Ole Begemann via swift-evolution <swift-evolution@swift.org> wrote:

This is subtle and requires thought

What do you envision as the pitfalls of the design thinking behind if/switch expressions? I’m not a compiler programmer, but a prog-lang enthusiast. I wouldn’t mind a little nudge in the right direction.

One thing that comes to mind is that if "if" is an expression, every if needs an else branch. This makes it harder to use if to conditionally perform side effects. For example, this is currently valid:

func doSomething() { ... }

if condition {
  doSomething()
}

Should this be allowed? You could argue that this should work because (a) the expression result is unused and (b) the return type of doSomething is Void, so the compiler could conceivably implicitly construct an else branch that returns (). But it would be inconsistent with other expressions. Disallowing this style could make writing typical "imperative" code harder.

– Ole