[swift-evolution] ternary operator ?: suggestion

Sun Dec 20 10:57:30 CST 2015

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 <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Dec 19, 2015, at 8:37 PM, Dennis Lysenko via swift-evolution <swift-evolution at swift.org <mailto: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 <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>
> 
> 
>  _______________________________________________
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/97be55f2/attachment.html>