ternary operator ?: suggestion

[possen (Paul Ossenbruggen)]

Thanks, great feedback!

Good point about the floats, that is definitely a hole in my proposal! I will update it with that.

To the list form being confusing, I would definitely like to know if others agree that having the two forms is confusing. The list form would be zero based. I would definitely drop it from the proposal if it would lead to it being declined but I think it is nice because it is concise and serves a valuable purpose of choosing among many choices without having to write out each case.

The alternate form, in alternatives considered, a variant of Vestor Godfied’s suggestion, is:

if (x==y : true, false)
switch (control : .North:”N”, .South:”S”, .East:”E”, .West:”W”, default:” “)
select (control : “A”, “B”, “C”, default:”D”)

may be preferred if others agree that it is confusing to have the list form and the case form together. Since Swift leaves parenthesis available around if and switch statements, the parenthesis colon sequence could be used to distinguish the statement and expression form. One thing I really don’t like about it is, that Swift finally solved the problem people running the space up against the parenthesis, something that had bothered me for some time, this would make the practice ingrained if(control : true, false) would become the norm. I suppose in this case it would make sense though.

Or if making it even more explicit we could combine the forms.

if? (x==y : true, false)
switch? (control : .North:”N”, .South:”S”, .East:”E”, .West:”W”, default:” “)
select? (control : “A”, “B”, “C”, default:”D”)

I expect that that may be more controversial though. As it then steps into the optionals area.

With both these options we lose some conciseness. So I still prefer the form in the proposal.

- Paul

···

On Dec 19, 2015, at 2:43 AM, Conrad Kutsch via swift-evolution <swift-evolution@swift.org> wrote:

Hey, I really like the new proposal, gets a +1from me! Especially the case part makes it good to use. I would just leave out the Integer part because it can be confusing and misleading. Do you start counting at 1? Or at 0? MinInt? It’s just super error-prone if you don’t write the number before it.

?(charNum : 0: "A", 1: "B”, ...
might be OK as it would get rid of the many case statements but then again, is this only working for Int or also for float?

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

Thanks for your support!

I think parenthesis are preferred because braces are for bracketing lists of statements. Statements may or may not return values.

Having the conditional on the inside of the parens helps to show the begging of the demux operator rather than a floating conditional which is a common complaint with the ternary operator.

On Dec 18, 2015, at 3:46 PM, Charles Constant <charles@charlesism.com <mailto:charles@charlesism.com>> wrote:

+1

I'd be very happy with your new proposal too. I still prefer sticking the value we're using as a key outside of the parens, but it's a minor quibble. Also I can't figure out if parens or curly braces are more appropriate. Does it make more sense for the expression to look like a tuple or a closure? I'm not sure.

Anyhow, I'm good with your new proposal.

_______________________________________________
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

[possen (Paul Ossenbruggen)]

+1 to Jordan's points as well.

Generally speaking, there is clearly a wide variety of things that cause people to be interested in this particular proposal and I don't think we can reconcile all of them. For example, I think that "collapsing an if statement into one line" isn't a good enough reason to introduce the clutter and potential for abuse of the original ternary syntax into a codebase, so I generally float the idea to ban it from projects I'm involved in as soon as I see it pop up in one. At the same time, there seem to be people who are enamored with the concept, and maybe instead they talk in this thread because they want a way to condense a switch statement into one line. And still others think that there is no rush to think about getting rid of ternary, unless we come up with something equally concise or with significant advantages to warrant removing it (all valid points).

I'm not against Paul's idea, but if it matters at all (i.e. if you are worried other people will think like me), if this syntax is released, I will most likely float the idea of opting out of it immediately to my project collaborators.

While interesting for quick, proof of concept coding sessions, it already has some of the readability and abusability disadvantages already present in ternary, and it's still just in the proposal stage.

I only hope that this doesn't preclude progress on turning fully-qualified (and indented) statements into expressions.

Good feedback!

Personally, I kind of hope that that is not the direction of Swift. I think there is quite a bit of value in keeping expressions and statements as separate concepts. If you need to do a bunch of things to get the result of an expression then use the statement construct or move it into a method.

Having statements that act as expressions encourages code that has side effects, which goes against one of the core concepts of functional programming. If I am working on a team, and someone wants to add some new feature and they see a big indented “if” with braces, they will just stick it in there and ignore that it is a functional approach. That new statement they add may add a bunch of side effects and add bugs to the code. If it is an expression that temptation will be less likely. They will see that this code is intended to work as an expression and won’t be able to just stick another statement with a bunch of side effects into it.

My proposal is about making expressions into first class citizens in terms of control flow. Its main purpose is definitely not about doing things on one line, that is just a side benefit if it works for your particular situation. This proposal supports and encourages multiline formatting and I think actually makes things cleaner and clearer than the statement forms.

But this feedback and Jordan’s is making me think that the Hybrid approach in Alternatives Considered may be more appealing to everyone. I was thinking conciseness might be preferable given some of the feedback I got from Chris and others, but after reading some other threads, clarity wins out over conciseness. This alternative may win for clarity. So I might go back and rethink that, but before I do that, I hope that more people could tell me if they like it better or do they like the ?( syntax better.

- Paul

···

On Dec 19, 2015, at 8:37 PM, Dennis Lysenko via swift-evolution <swift-evolution@swift.org> wrote:

On Sat, Dec 19, 2015 at 10:57 PM Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> It's a nice, consistent proposal, but I don't feel like this solves any of the complaints about the existing ternary operator:
>
> - It's not obvious what it does when you first learn it.
> - The '?' doesn't have anything to do with Optionals.
>
> It is a way to put 'switch' into an expression. I'm not a fan of the two different colons, but that's "just" syntax.

+1 to all that

> Jordan
>
>> On Dec 18, 2015, at 14:04 , Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> All,
>>
>> I think, I finally might have the answer to improving ternary, with such a bold statement come some pretty high expectations but I think, I might actually have done it this time :-)
>>
>> I am calling it the Demux Expression, it builds on the benefits of ternary and switch while improving on those.
>>
>> https://github.com/possen/swift-evolution/blob/master/proposals/0024.md
>>
>> This is a first draft, thanks in advance for feedback!
>>
>> - Paul
>> _______________________________________________
>> 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

-Dave

_______________________________________________
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

[anandabits (Matthew Johnson)]

I'm with Matthew/Craig.

We discussed a couple very ternary-like versions earlier in the thread, which I increasingly think are the best options.

The major objection to this came from Lattner, and his objection, if I have it right, is "this proposal doesn't add enough functionality to justify the additional complexity/confusion"

The sticking point, at the moment, is formulating a really persuasive argument for "why we need this." If we can't do that, this proposal is dead.

I was originally hoping we could remove ternary and just make if and switch expressions.

However, It seems to be clear that 1) there are enough challenges to making if and switch expressions that it won’t happen any time soon, if ever and 2) the conciseness of ternary is highly valued and it will be hard to beat it on conciseness.

Given that, a ternary-like switch expression seems pretty valuable IMO. I think concrete examples showing how it helps to increase readability over: 1) switch statements and 2) immediately invoked closures are the best way to demonstrate the need for this feature.

···

On Dec 29, 2015, at 8:54 AM, Charles Constant <charles@charlesism.com> wrote:

On Tue, Dec 29, 2015 at 5:38 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPad

On Dec 29, 2015, at 7:28 AM, Craig Cruden via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

That looks pretty ugly.

I think the best we can hope for at this point is maybe another keyword that mirrors switch but is expression based (aka match) — leaving the ternary ? : expression as is - which is not all that bad since any if else that becomes a compound expression or more than two resultant values (chaining) quickly becomes a mess.

I agree that this is probably the best path forward at the moment. There was a post early on showing a ternary-like switch expression. I don't remember whether there were any specific problems with that idea or not, but if there aren't that might best route forward.

I am not sure that even a “match” expression would be accepted at this point because there seems to be general resistance to anything more than the existing paradigm with a few functional decorations — and the way of doing things is good enough.

Concurrency is also currently off the table at this point -- the fact that immutable pure functional code can theoretically be parsed into a dependance graph which would allow for out of order [within scope] parallel execution on different threads [not sure if the overhead of doing so would outweigh the benefits]…. would also not be of sufficient benefit.

The primary focus of Swift is a language for UI development, not server development….

On 2015-12-29, at 15:07:57, James Campbell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What if you could wrap the existing switch statement in a closure and return a value from that closure like so

Let value = { switch (other) {
Case .Some(let value):
Return value // because this is in a closure the closure will return the value not the function this is in
Case .None:
Return "hello"
}}

Sent from my iPhone

On 29 Dec 2015, at 07:53, Howard Lovatt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

You can replace the proposed statement `which` (another thread), the existing statement `?:` (this thread), and the global function `??` (which is an odd ball) with matching library methods.

A library method is likely slower than a built in at this stage until the optimiser improves, but a library function:

Is documented right in the IDE including code completion, statements aren’t (you don’t see quick help for `for`!)
Having a library function allows the use case to be throughly investigated. Is worth while as a language statement? What exact features are useful? EG should `which` support pattern matching, general boolean expressions, or simply be `Equatable` as shown below?
It is simpler to implement, maintain, and change a library function that a built-in.
There is no need for a keyword.

First `which`:

// Alternative to introducing `which` statement

final
class Which<I: Equatable, R> {
    private
    var result: R?
    
    private
    let which: I
    
    init(_ which: I) {
        self.which = which
    }
    
    func match(value: I, @noescape matchResult: () throws -> R) rethrows -> Self {
        if self.result == nil && self.which == value {
            self.result = try matchResult()
        }
        return self
    }
    
    func matchDefault(@noescape defaultResult: () throws -> R) rethrows -> R {
        switch self.result {
        case .None:
            return try defaultResult()
        case .Some(let value):
            return value
        }
    }
}

// Demo
enum Color {
    case Red, Blue, Green
}

// Which with a default value
let i1 = Which(Color.Red) // i = 16711680 <tel:16711680>
    .match(.Red) { 0xFF0000 }
    .match(.Green) { 0x00FF00 }
    .match(.Blue) { 0x00000FF }
    .matchDefault { 0 }

// Which that throws an error if it defaults
let i2: Int! = Which(Color.Green) // i = 16711680 <tel:16711680>
    .match(.Red) { 0xFF0000 }
    .match(.Green) { 0x00FF00 }
    .match(.Blue) { 0x00000FF }
    .matchDefault { nil } // Cant type call to fatalError as no return, hence nil and type Int! (note !)

Note runtime check for default rather than static check via compiler, not as good but not a big deal most of the time. The vast majority of languages don't do a compiler check on `switch`.

Similarly the `?:` statement can be replaced:

// Replacement for `?:` operator

struct IfFalse<R> {
    private
    let result: R?
    
    func ifFalse(@noescape falseResult: () throws -> R) rethrows -> R {
        switch self.result {
        case .None:
            return try falseResult()
        case .Some(let value):
            return value
        }
    }
}

extension Bool {
    func ifTrue<R>(@noescape trueResult: () throws -> R) rethrows -> IfFalse<R> {
        switch self {
        case true:
            return IfFalse(result: try trueResult())
        case false:
            return IfFalse(result: nil)
        }
    }
}

// Demo
let sB = true.ifTrue{"True"}.ifFalse{"False"} // "True" - for some reason needs {} and not () thinks () form throws

Whilst the `??` operator is already a library function it is difficult to see in an expression, it gets buried, and is inconsistent in style because it is a non-mathematical operator and a symbol rather than a keyword or keyword followed by a symbol. The space either side of the `??` operator also makes it look like both arguments are of equal importance, whereas it is the left hand side that is important and the right hand side is just a catch.

// Replacement for `??` operator

extension Optional {
    func ifNil(@noescape nilResult: () throws -> Wrapped) rethrows -> Wrapped {
        switch self {
        case .None:
            return try nilResult()
        case .Some(let value):
            return value
        }
    }
}

// Demo
let o: String? = nil
let sO = o.ifNil{"Nil"} // "Nil" - for some reason needs {} and not () thinks () form throws

Sent from my iPad

On 29 Dec 2015, at 4:00 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

No exhaustiveness checking is a serious deficiency :-(

-Thorsten

Am 17.12.2015 um 08:09 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

Actually, this *almost* does what you want. No @autoclosure for the values and no exhaustiveness checking, but otherwise...

_______________________________________________
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

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

[Charles_Constant]

keeping expressions and statements as separate concepts

I seriously could not care less about that.

Wait wait, I'm exaggerating! I wouldn't want Swift to become a language
like Javascript where you forget to type a single character, and discover
your program runs without complaint (assigning some bizarre boolean value
as a result).

But if we're talking about the 'Switch' statement, as originally proposed,
it takes a lot more characters, and luck, to get your app to compile and
run. For me, I'd way rather have the convenience. As far as I'm concerned,
unless I'm choosing a variable name, the more I have to type, the more
likely I'm going to make a mistake.

This is why I think the ternary, for example, gets a bad rap (a bad rap *at
the moment* anyway. I can't keep track, are "goto" and OOP bad this year?).
The clarity you gain with a ternary is the fact that "this statement exists
to assign a value to Foo." You break that into several lines, and that
clarity can evaporate into the ether.

So the reason I like your proposal, is that I want a way to preserve that
clarity of "this line exists to assign a value to Foo" when I'm mapping
something. The existing options, i.e.: the alternatives about I complained
earlier in this thread, leave me with extra code whose purpose is solely to
support that assignment to Foo. So, let's say I do it by extending an enum
with an init that has a corresponding set of values... the purpose of that
extension is no longer as clear (e.g.: "this init exists to support a line,
somewhere else in this file, that assigns a value to Foo"). If I use a
Switch statement, as it currently exists, it's a bunch of lines - and don't
forget that "let Foo" needs to be declared *before* the Switch statement
because of scope... it's so much more complicated than your proposal.

I don't know if I added anything helpful here other than complaining :)
Needless to say, I still support your proposal

···

On Sat, Dec 19, 2015 at 9:57 PM, Paul Ossenbruggen via swift-evolution < swift-evolution@swift.org> wrote:

On Dec 19, 2015, at 8:37 PM, Dennis Lysenko via swift-evolution < > swift-evolution@swift.org> wrote:

+1 to Jordan's points as well.

Generally speaking, there is clearly a wide variety of things that cause
people to be interested in this particular proposal and I don't think we
can reconcile all of them. For example, I think that "collapsing an if
statement into one line" isn't a good enough reason to introduce the
clutter and potential for abuse of the original ternary syntax into a
codebase, so I generally float the idea to ban it from projects I'm
involved in as soon as I see it pop up in one. At the same time, there seem
to be people who are enamored with the concept, and maybe instead they talk
in this thread because they want a way to condense a switch statement into
one line. And still others think that there is no rush to think about
getting rid of ternary, unless we come up with something equally concise or
with significant advantages to warrant removing it (all valid points).

I'm not *against* Paul's idea, but if it matters at all (i.e. if you are
worried other people will think like me), if this syntax is released, I
will most likely float the idea of opting out of it immediately to my
project collaborators.

While interesting for quick, proof of concept coding sessions, it already
has some of the readability and abusability disadvantages already present
in ternary, and it's still just in the proposal stage.

I only hope that this doesn't preclude progress on turning fully-qualified
(and indented) statements into expressions.

Good feedback!

Personally, I kind of hope that that is not the direction of Swift. I
think there is quite a bit of value in keeping expressions and statements
as separate concepts. If you need to do a bunch of things to get the result
of an expression then use the statement construct or move it into a method.

Having statements that act as expressions encourages code that has side
effects, which goes against one of the core concepts of functional
programming. If I am working on a team, and someone wants to add some new
feature and they see a big indented “if” with braces, they will just stick
it in there and ignore that it is a functional approach. That new statement
they add may add a bunch of side effects and add bugs to the code. If it is
an expression that temptation will be less likely. They will see that this
code is intended to work as an expression and won’t be able to just stick
another statement with a bunch of side effects into it.

My proposal is about making expressions into first class citizens in terms
of control flow. Its main purpose is definitely not about doing things on
one line, that is just a side benefit if it works for your particular
situation. This proposal supports and encourages multiline formatting and I
think actually makes things cleaner and clearer than the statement forms.

But this feedback and Jordan’s is making me think that the Hybrid approach
in Alternatives Considered may be more appealing to everyone. I was
thinking conciseness might be preferable given some of the feedback I got
from Chris and others, but after reading some other threads, clarity wins
out over conciseness. This alternative may win for clarity. So I might go
back and rethink that, but before I do that, I hope that more people could
tell me if they like it better or do they like the ?( syntax better.

- Paul

On Sat, Dec 19, 2015 at 10:57 PM Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

> On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> It's a nice, consistent proposal, but I don't feel like this solves any
of the complaints about the existing ternary operator:
>
> - It's not obvious what it does when you first learn it.
> - The '?' doesn't have anything to do with Optionals.
>
> It is a way to put 'switch' into an expression. I'm not a fan of the
two different colons, but that's "just" syntax.

+1 to all that

> Jordan
>
>> On Dec 18, 2015, at 14:04 , Paul Ossenbruggen via swift-evolution < >> swift-evolution@swift.org> wrote:
>>
>> All,
>>
>> I think, I finally might have the answer to improving ternary, with
such a bold statement come some pretty high expectations but I think, I
might actually have done it this time :-)
>>
>> I am calling it the Demux Expression, it builds on the benefits of
ternary and switch while improving on those.
>>
>>
https://github.com/possen/swift-evolution/blob/master/proposals/0024.md
>>
>> This is a first draft, thanks in advance for feedback!
>>
>> - Paul
>> _______________________________________________
>> 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

-Dave

_______________________________________________
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

[Stephen_Canon]

Paul, does the proposed operator short-circuit like ternary does (i.e. is only the active case evaluated)?

– Steve

···

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

Thanks, great feedback!

Good point about the floats, that is definitely a hole in my proposal! I will update it with that.

To the list form being confusing, I would definitely like to know if others agree that having the two forms is confusing. The list form would be zero based. I would definitely drop it from the proposal if it would lead to it being declined but I think it is nice because it is concise and serves a valuable purpose of choosing among many choices without having to write out each case.

The alternate form, in alternatives considered, a variant of Vestor Godfied’s suggestion, is:

if (x==y : true, false)
switch (control : .North:”N”, .South:”S”, .East:”E”, .West:”W”, default:” “)
select (control : “A”, “B”, “C”, default:”D”)

may be preferred if others agree that it is confusing to have the list form and the case form together. Since Swift leaves parenthesis available around if and switch statements, the parenthesis colon sequence could be used to distinguish the statement and expression form. One thing I really don’t like about it is, that Swift finally solved the problem people running the space up against the parenthesis, something that had bothered me for some time, this would make the practice ingrained if(control : true, false) would become the norm. I suppose in this case it would make sense though.

Or if making it even more explicit we could combine the forms.

if? (x==y : true, false)
switch? (control : .North:”N”, .South:”S”, .East:”E”, .West:”W”, default:” “)
select? (control : “A”, “B”, “C”, default:”D”)

I expect that that may be more controversial though. As it then steps into the optionals area.

With both these options we lose some conciseness. So I still prefer the form in the proposal.

- Paul

On Dec 19, 2015, at 2:43 AM, Conrad Kutsch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hey, I really like the new proposal, gets a +1from me! Especially the case part makes it good to use. I would just leave out the Integer part because it can be confusing and misleading. Do you start counting at 1? Or at 0? MinInt? It’s just super error-prone if you don’t write the number before it.

?(charNum : 0: "A", 1: "B”, ...
might be OK as it would get rid of the many case statements but then again, is this only working for Int or also for float?

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

Thanks for your support!

I think parenthesis are preferred because braces are for bracketing lists of statements. Statements may or may not return values.

Having the conditional on the inside of the parens helps to show the begging of the demux operator rather than a floating conditional which is a common complaint with the ternary operator.

On Dec 18, 2015, at 3:46 PM, Charles Constant <charles@charlesism.com <mailto:charles@charlesism.com>> wrote:

+1

I'd be very happy with your new proposal too. I still prefer sticking the value we're using as a key outside of the parens, but it's a minor quibble. Also I can't figure out if parens or curly braces are more appropriate. Does it make more sense for the expression to look like a tuple or a closure? I'm not sure.

Anyhow, I'm good with your new proposal.

_______________________________________________
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

[possen (Paul Ossenbruggen)]

Yes definitely. This should be in the proposal. Thanks.

···

On Dec 20, 2015, at 8:53 AM, Stephen Canon <scanon@apple.com> wrote:

Paul, does the proposed operator short-circuit like ternary does (i.e. is only the active case evaluated)?

– Steve

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

Thanks, great feedback!

Good point about the floats, that is definitely a hole in my proposal! I will update it with that.

To the list form being confusing, I would definitely like to know if others agree that having the two forms is confusing. The list form would be zero based. I would definitely drop it from the proposal if it would lead to it being declined but I think it is nice because it is concise and serves a valuable purpose of choosing among many choices without having to write out each case.

The alternate form, in alternatives considered, a variant of Vestor Godfied’s suggestion, is:

if (x==y : true, false)
switch (control : .North:”N”, .South:”S”, .East:”E”, .West:”W”, default:” “)
select (control : “A”, “B”, “C”, default:”D”)

may be preferred if others agree that it is confusing to have the list form and the case form together. Since Swift leaves parenthesis available around if and switch statements, the parenthesis colon sequence could be used to distinguish the statement and expression form. One thing I really don’t like about it is, that Swift finally solved the problem people running the space up against the parenthesis, something that had bothered me for some time, this would make the practice ingrained if(control : true, false) would become the norm. I suppose in this case it would make sense though.

Or if making it even more explicit we could combine the forms.

if? (x==y : true, false)
switch? (control : .North:”N”, .South:”S”, .East:”E”, .West:”W”, default:” “)
select? (control : “A”, “B”, “C”, default:”D”)

I expect that that may be more controversial though. As it then steps into the optionals area.

With both these options we lose some conciseness. So I still prefer the form in the proposal.

- Paul

On Dec 19, 2015, at 2:43 AM, Conrad Kutsch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hey, I really like the new proposal, gets a +1from me! Especially the case part makes it good to use. I would just leave out the Integer part because it can be confusing and misleading. Do you start counting at 1? Or at 0? MinInt? It’s just super error-prone if you don’t write the number before it.

?(charNum : 0: "A", 1: "B”, ...
might be OK as it would get rid of the many case statements but then again, is this only working for Int or also for float?

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

Thanks for your support!

I think parenthesis are preferred because braces are for bracketing lists of statements. Statements may or may not return values.

Having the conditional on the inside of the parens helps to show the begging of the demux operator rather than a floating conditional which is a common complaint with the ternary operator.

On Dec 18, 2015, at 3:46 PM, Charles Constant <charles@charlesism.com <mailto:charles@charlesism.com>> wrote:

+1

I'd be very happy with your new proposal too. I still prefer sticking the value we're using as a key outside of the parens, but it's a minor quibble. Also I can't figure out if parens or curly braces are more appropriate. Does it make more sense for the expression to look like a tuple or a closure? I'm not sure.

Anyhow, I'm good with your new proposal.

_______________________________________________
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

[Craig_Cruden]

The complaint that you have about Javascript is more a function of it not being a strongly typed language. If you were to write a function with the type of return specified and the code inside the function (because of a single character) end up changing type for the return value or a future expression that was not expecting boolean…. then it would not compile.

···

On 2015-12-20, at 13:35:42, Charles Constant via swift-evolution <swift-evolution@swift.org> wrote:

> keeping expressions and statements as separate concepts

I seriously could not care less about that.

Wait wait, I'm exaggerating! I wouldn't want Swift to become a language like Javascript where you forget to type a single character, and discover your program runs without complaint (assigning some bizarre boolean value as a result).

But if we're talking about the 'Switch' statement, as originally proposed, it takes a lot more characters, and luck, to get your app to compile and run. For me, I'd way rather have the convenience. As far as I'm concerned, unless I'm choosing a variable name, the more I have to type, the more likely I'm going to make a mistake.

This is why I think the ternary, for example, gets a bad rap (a bad rap *at the moment* anyway. I can't keep track, are "goto" and OOP bad this year?). The clarity you gain with a ternary is the fact that "this statement exists to assign a value to Foo." You break that into several lines, and that clarity can evaporate into the ether.

So the reason I like your proposal, is that I want a way to preserve that clarity of "this line exists to assign a value to Foo" when I'm mapping something. The existing options, i.e.: the alternatives about I complained earlier in this thread, leave me with extra code whose purpose is solely to support that assignment to Foo. So, let's say I do it by extending an enum with an init that has a corresponding set of values... the purpose of that extension is no longer as clear (e.g.: "this init exists to support a line, somewhere else in this file, that assigns a value to Foo"). If I use a Switch statement, as it currently exists, it's a bunch of lines - and don't forget that "let Foo" needs to be declared *before* the Switch statement because of scope... it's so much more complicated than your proposal.

I don't know if I added anything helpful here other than complaining :) Needless to say, I still support your proposal

On Sat, Dec 19, 2015 at 9:57 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 19, 2015, at 8:37 PM, Dennis Lysenko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1 to Jordan's points as well.

Generally speaking, there is clearly a wide variety of things that cause people to be interested in this particular proposal and I don't think we can reconcile all of them. For example, I think that "collapsing an if statement into one line" isn't a good enough reason to introduce the clutter and potential for abuse of the original ternary syntax into a codebase, so I generally float the idea to ban it from projects I'm involved in as soon as I see it pop up in one. At the same time, there seem to be people who are enamored with the concept, and maybe instead they talk in this thread because they want a way to condense a switch statement into one line. And still others think that there is no rush to think about getting rid of ternary, unless we come up with something equally concise or with significant advantages to warrant removing it (all valid points).

I'm not against Paul's idea, but if it matters at all (i.e. if you are worried other people will think like me), if this syntax is released, I will most likely float the idea of opting out of it immediately to my project collaborators.

While interesting for quick, proof of concept coding sessions, it already has some of the readability and abusability disadvantages already present in ternary, and it's still just in the proposal stage.

I only hope that this doesn't preclude progress on turning fully-qualified (and indented) statements into expressions.

Good feedback!

Personally, I kind of hope that that is not the direction of Swift. I think there is quite a bit of value in keeping expressions and statements as separate concepts. If you need to do a bunch of things to get the result of an expression then use the statement construct or move it into a method.

Having statements that act as expressions encourages code that has side effects, which goes against one of the core concepts of functional programming. If I am working on a team, and someone wants to add some new feature and they see a big indented “if” with braces, they will just stick it in there and ignore that it is a functional approach. That new statement they add may add a bunch of side effects and add bugs to the code. If it is an expression that temptation will be less likely. They will see that this code is intended to work as an expression and won’t be able to just stick another statement with a bunch of side effects into it.

My proposal is about making expressions into first class citizens in terms of control flow. Its main purpose is definitely not about doing things on one line, that is just a side benefit if it works for your particular situation. This proposal supports and encourages multiline formatting and I think actually makes things cleaner and clearer than the statement forms.

But this feedback and Jordan’s is making me think that the Hybrid approach in Alternatives Considered may be more appealing to everyone. I was thinking conciseness might be preferable given some of the feedback I got from Chris and others, but after reading some other threads, clarity wins out over conciseness. This alternative may win for clarity. So I might go back and rethink that, but before I do that, I hope that more people could tell me if they like it better or do they like the ?( syntax better.

- Paul

On Sat, Dec 19, 2015 at 10:57 PM Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> It's a nice, consistent proposal, but I don't feel like this solves any of the complaints about the existing ternary operator:
>
> - It's not obvious what it does when you first learn it.
> - The '?' doesn't have anything to do with Optionals.
>
> It is a way to put 'switch' into an expression. I'm not a fan of the two different colons, but that's "just" syntax.

+1 to all that

> Jordan
>
>> On Dec 18, 2015, at 14:04 , Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> All,
>>
>> I think, I finally might have the answer to improving ternary, with such a bold statement come some pretty high expectations but I think, I might actually have done it this time :-)
>>
>> I am calling it the Demux Expression, it builds on the benefits of ternary and switch while improving on those.
>>
>> https://github.com/possen/swift-evolution/blob/master/proposals/0024.md
>>
>> This is a first draft, thanks in advance for feedback!
>>
>> - Paul
>> _______________________________________________
>> 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

-Dave

_______________________________________________
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

[Charles_Constant]

Paul, I'm not keen on this:

?(cond : “A” else: “B”)

Not that chaining ternary conditions is a good idea, but people will do it
anyways. If we're using else, we may as well go with ( cond true:“A” false:
“B”) which is easier or a human to parse, imo.

Craig,

The complaint that you have about Javascript

Cheers, you're right. I ought to have spent more time thinking of a good
example. The idea I was trying to express is that being absolutist about
language features doesn't appeal to me. Or maybe I am absolutist, but just
have different preferences. In any event, it appeals more to me to have a
Switch assignment that echoes the syntax of a normal Switch statement, than
it does to maintain "expressions and statements as separate concepts".

···

On Sun, Dec 20, 2015 at 8:57 AM, Craig Cruden <ccruden@novafore.com> wrote:

The complaint that you have about Javascript is more a function of it not
being a strongly typed language. If you were to write a function with the
type of return specified and the code inside the function (because of a
single character) end up changing type for the return value or a future
expression that was not expecting boolean…. then it would not compile.

On 2015-12-20, at 13:35:42, Charles Constant via swift-evolution < > swift-evolution@swift.org> wrote:

> keeping expressions and statements as separate concepts

I seriously could not care less about that.

Wait wait, I'm exaggerating! I wouldn't want Swift to become a language
like Javascript where you forget to type a single character, and discover
your program runs without complaint (assigning some bizarre boolean value
as a result).

But if we're talking about the 'Switch' statement, as originally proposed,
it takes a lot more characters, and luck, to get your app to compile and
run. For me, I'd way rather have the convenience. As far as I'm concerned,
unless I'm choosing a variable name, the more I have to type, the more
likely I'm going to make a mistake.

This is why I think the ternary, for example, gets a bad rap (a bad rap
*at the moment* anyway. I can't keep track, are "goto" and OOP bad this
year?). The clarity you gain with a ternary is the fact that "this
statement exists to assign a value to Foo." You break that into several
lines, and that clarity can evaporate into the ether.

So the reason I like your proposal, is that I want a way to preserve that
clarity of "this line exists to assign a value to Foo" when I'm mapping
something. The existing options, i.e.: the alternatives about I complained
earlier in this thread, leave me with extra code whose purpose is solely to
support that assignment to Foo. So, let's say I do it by extending an enum
with an init that has a corresponding set of values... the purpose of that
extension is no longer as clear (e.g.: "this init exists to support a line,
somewhere else in this file, that assigns a value to Foo"). If I use a
Switch statement, as it currently exists, it's a bunch of lines - and don't
forget that "let Foo" needs to be declared *before* the Switch statement
because of scope... it's so much more complicated than your proposal.

I don't know if I added anything helpful here other than complaining :)
Needless to say, I still support your proposal

On Sat, Dec 19, 2015 at 9:57 PM, Paul Ossenbruggen via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 19, 2015, at 8:37 PM, Dennis Lysenko via swift-evolution < >> swift-evolution@swift.org> wrote:

+1 to Jordan's points as well.

Generally speaking, there is clearly a wide variety of things that cause
people to be interested in this particular proposal and I don't think we
can reconcile all of them. For example, I think that "collapsing an if
statement into one line" isn't a good enough reason to introduce the
clutter and potential for abuse of the original ternary syntax into a
codebase, so I generally float the idea to ban it from projects I'm
involved in as soon as I see it pop up in one. At the same time, there seem
to be people who are enamored with the concept, and maybe instead they talk
in this thread because they want a way to condense a switch statement into
one line. And still others think that there is no rush to think about
getting rid of ternary, unless we come up with something equally concise or
with significant advantages to warrant removing it (all valid points).

I'm not *against* Paul's idea, but if it matters at all (i.e. if you are
worried other people will think like me), if this syntax is released, I
will most likely float the idea of opting out of it immediately to my
project collaborators.

While interesting for quick, proof of concept coding sessions, it already
has some of the readability and abusability disadvantages already present
in ternary, and it's still just in the proposal stage.

I only hope that this doesn't preclude progress on turning
fully-qualified (and indented) statements into expressions.

Good feedback!

Personally, I kind of hope that that is not the direction of Swift. I
think there is quite a bit of value in keeping expressions and statements
as separate concepts. If you need to do a bunch of things to get the result
of an expression then use the statement construct or move it into a method.

Having statements that act as expressions encourages code that has side
effects, which goes against one of the core concepts of functional
programming. If I am working on a team, and someone wants to add some new
feature and they see a big indented “if” with braces, they will just stick
it in there and ignore that it is a functional approach. That new statement
they add may add a bunch of side effects and add bugs to the code. If it is
an expression that temptation will be less likely. They will see that this
code is intended to work as an expression and won’t be able to just stick
another statement with a bunch of side effects into it.

My proposal is about making expressions into first class citizens in
terms of control flow. Its main purpose is definitely not about doing
things on one line, that is just a side benefit if it works for your
particular situation. This proposal supports and encourages multiline
formatting and I think actually makes things cleaner and clearer than the
statement forms.

But this feedback and Jordan’s is making me think that the Hybrid
approach in Alternatives Considered may be more appealing to everyone. I
was thinking conciseness might be preferable given some of the feedback I
got from Chris and others, but after reading some other threads, clarity
wins out over conciseness. This alternative may win for clarity. So I might
go back and rethink that, but before I do that, I hope that more people
could tell me if they like it better or do they like the ?( syntax better.

- Paul

On Sat, Dec 19, 2015 at 10:57 PM Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote:

> On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution < >>> swift-evolution@swift.org> wrote:
>
> It's a nice, consistent proposal, but I don't feel like this solves
any of the complaints about the existing ternary operator:
>
> - It's not obvious what it does when you first learn it.
> - The '?' doesn't have anything to do with Optionals.
>
> It is a way to put 'switch' into an expression. I'm not a fan of the
two different colons, but that's "just" syntax.

+1 to all that

> Jordan
>
>> On Dec 18, 2015, at 14:04 , Paul Ossenbruggen via swift-evolution < >>> swift-evolution@swift.org> wrote:
>>
>> All,
>>
>> I think, I finally might have the answer to improving ternary, with
such a bold statement come some pretty high expectations but I think, I
might actually have done it this time :-)
>>
>> I am calling it the Demux Expression, it builds on the benefits of
ternary and switch while improving on those.
>>
>>
https://github.com/possen/swift-evolution/blob/master/proposals/0024.md
>>
>> This is a first draft, thanks in advance for feedback!
>>
>> - Paul
>> _______________________________________________
>> 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

-Dave

_______________________________________________
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

[Craig_Cruden]

Addendum,

ternary for simple things like:

  let name = (gender == female) ? “Jill” : “Joe”

Anything more than that then it becomes a hairy mess.

BTW, OOP is good for some solutions, bad for others. But goto is only good in assembly language (IMHO :p).

I would pretty well prefer everything except for assignments (let/var) to be expressions.

···

On 2015-12-20, at 23:57:30, Craig Cruden <ccruden@novafore.com> wrote:

The complaint that you have about Javascript is more a function of it not being a strongly typed language. If you were to write a function with the type of return specified and the code inside the function (because of a single character) end up changing type for the return value or a future expression that was not expecting boolean…. then it would not compile.

On 2015-12-20, at 13:35:42, Charles Constant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> keeping expressions and statements as separate concepts

I seriously could not care less about that.

Wait wait, I'm exaggerating! I wouldn't want Swift to become a language like Javascript where you forget to type a single character, and discover your program runs without complaint (assigning some bizarre boolean value as a result).

But if we're talking about the 'Switch' statement, as originally proposed, it takes a lot more characters, and luck, to get your app to compile and run. For me, I'd way rather have the convenience. As far as I'm concerned, unless I'm choosing a variable name, the more I have to type, the more likely I'm going to make a mistake.

This is why I think the ternary, for example, gets a bad rap (a bad rap *at the moment* anyway. I can't keep track, are "goto" and OOP bad this year?). The clarity you gain with a ternary is the fact that "this statement exists to assign a value to Foo." You break that into several lines, and that clarity can evaporate into the ether.

So the reason I like your proposal, is that I want a way to preserve that clarity of "this line exists to assign a value to Foo" when I'm mapping something. The existing options, i.e.: the alternatives about I complained earlier in this thread, leave me with extra code whose purpose is solely to support that assignment to Foo. So, let's say I do it by extending an enum with an init that has a corresponding set of values... the purpose of that extension is no longer as clear (e.g.: "this init exists to support a line, somewhere else in this file, that assigns a value to Foo"). If I use a Switch statement, as it currently exists, it's a bunch of lines - and don't forget that "let Foo" needs to be declared *before* the Switch statement because of scope... it's so much more complicated than your proposal.

I don't know if I added anything helpful here other than complaining :) Needless to say, I still support your proposal

On Sat, Dec 19, 2015 at 9:57 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 19, 2015, at 8:37 PM, Dennis Lysenko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1 to Jordan's points as well.

Generally speaking, there is clearly a wide variety of things that cause people to be interested in this particular proposal and I don't think we can reconcile all of them. For example, I think that "collapsing an if statement into one line" isn't a good enough reason to introduce the clutter and potential for abuse of the original ternary syntax into a codebase, so I generally float the idea to ban it from projects I'm involved in as soon as I see it pop up in one. At the same time, there seem to be people who are enamored with the concept, and maybe instead they talk in this thread because they want a way to condense a switch statement into one line. And still others think that there is no rush to think about getting rid of ternary, unless we come up with something equally concise or with significant advantages to warrant removing it (all valid points).

I'm not against Paul's idea, but if it matters at all (i.e. if you are worried other people will think like me), if this syntax is released, I will most likely float the idea of opting out of it immediately to my project collaborators.

While interesting for quick, proof of concept coding sessions, it already has some of the readability and abusability disadvantages already present in ternary, and it's still just in the proposal stage.

I only hope that this doesn't preclude progress on turning fully-qualified (and indented) statements into expressions.

Good feedback!

Personally, I kind of hope that that is not the direction of Swift. I think there is quite a bit of value in keeping expressions and statements as separate concepts. If you need to do a bunch of things to get the result of an expression then use the statement construct or move it into a method.

Having statements that act as expressions encourages code that has side effects, which goes against one of the core concepts of functional programming. If I am working on a team, and someone wants to add some new feature and they see a big indented “if” with braces, they will just stick it in there and ignore that it is a functional approach. That new statement they add may add a bunch of side effects and add bugs to the code. If it is an expression that temptation will be less likely. They will see that this code is intended to work as an expression and won’t be able to just stick another statement with a bunch of side effects into it.

My proposal is about making expressions into first class citizens in terms of control flow. Its main purpose is definitely not about doing things on one line, that is just a side benefit if it works for your particular situation. This proposal supports and encourages multiline formatting and I think actually makes things cleaner and clearer than the statement forms.

But this feedback and Jordan’s is making me think that the Hybrid approach in Alternatives Considered may be more appealing to everyone. I was thinking conciseness might be preferable given some of the feedback I got from Chris and others, but after reading some other threads, clarity wins out over conciseness. This alternative may win for clarity. So I might go back and rethink that, but before I do that, I hope that more people could tell me if they like it better or do they like the ?( syntax better.

- Paul

On Sat, Dec 19, 2015 at 10:57 PM Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> It's a nice, consistent proposal, but I don't feel like this solves any of the complaints about the existing ternary operator:
>
> - It's not obvious what it does when you first learn it.
> - The '?' doesn't have anything to do with Optionals.
>
> It is a way to put 'switch' into an expression. I'm not a fan of the two different colons, but that's "just" syntax.

+1 to all that

> Jordan
>
>> On Dec 18, 2015, at 14:04 , Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> All,
>>
>> I think, I finally might have the answer to improving ternary, with such a bold statement come some pretty high expectations but I think, I might actually have done it this time :-)
>>
>> I am calling it the Demux Expression, it builds on the benefits of ternary and switch while improving on those.
>>
>> https://github.com/possen/swift-evolution/blob/master/proposals/0024.md
>>
>> This is a first draft, thanks in advance for feedback!
>>
>> - Paul
>> _______________________________________________
>> 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

-Dave

_______________________________________________
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

[alexbbrown (Alex Brown)]

With if expressions, I think this issue is now essentially settled, and can be removed from the list of commonly rejected changes

The ternary expression

let result = !condition ? 1 : 2

Is expressible as the if expression

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

apple/swift-evolution/blob/main/commonly_proposed.md#miscellaneous

apple/swift-evolution/blob/main/proposals/0380-if-switch-expressions.md#full-expressions

[tera]

Please do not resurrect ancient threads! It's better to start a new one with a link to the original. Note that the ternary operation is not "replaced", we still have it.