[swift-evolution] ternary operator ?: suggestion

Sat Dec 19 23:57:10 CST 2015

> 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 <mailto:swift-evolution at swift.org>> wrote:
> 
> > On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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 <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 <mailto:swift-evolution at swift.org>
> >> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> -Dave
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/3cdc5b8e/attachment.html>