[swift-evolution] ternary operator ?: suggestion

Sun Dec 20 00:35:42 CST 2015

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151219/7b658300/attachment.html>