[swift-evolution] ternary operator ?: suggestion

Sun Dec 20 16:26:59 CST 2015

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 at 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 at 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 at swift.org> wrote:
>
>>
>> On Dec 19, 2015, at 8:37 PM, Dennis Lysenko via swift-evolution <
>> swift-evolution at 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 at swift.org> wrote:
>>
>>>
>>> > On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution <
>>> swift-evolution at 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 at 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 at swift.org
>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> >
>>> > _______________________________________________
>>> > swift-evolution mailing list
>>> > swift-evolution at swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> -Dave
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/8df7079c/attachment.html>