Remove ternary operator

[brson]

One of the comments that stuck with me after the 0.1 announcement was somebody asking why we have a ternary operator, since it is functionally the same as our if expressions. I'm sympathetic to this sentiment

Lately I have been feeling wary about the rapid addition of features to the language and think that we should be more cautious about committing to things we don't really need. One of the original mandates upon the announcement of Rust was to focus on removing features (it's in the language FAQ), and I don't think there's any way to argue that we have succeeded at that.

Admittedly, the ternary operator is a low-maintenance feature, but its removal is also low-impact.

[catamorphism]

I agree. I was wondering why we had the ternary operator, too.

[BrendanEich]

Agreed. Wish I had made JS an expression language. The great statement/expression split motivates ?: but Rust is free of that, and if-else suffices.

/be

[kevina]

As a very heavy user of the ?: operator in C/C++ I prefer the compact syntax. I also think it formats better when the expression is too long to fit on a single line:

let x = some_very_long_condational
     ? if_true
     : if_false

let x = if some_very_long_condational 
     { if_true}
     else { if_false}

The syntax can get worse, in my view, if if_true and if_false won't fit on a single line. For example, where should the braces be placed.

Just my two cents.

[ssylvan]

I like:

let x = if some_very_long_condational { 
                 if_true
           } else { 
                 if_false
           }

It adds some extra lines (the "else line" and the final bracket), but it keeps it clean and you can add as much code as you want in either.

I use the ternary operator a lot in C++, but I think the syntax is poor. You ave to spot the ? and : in the middle of a sea of other tokens to see that it's even a conditional. With expression-if you have the leading token indicating to the reader "here comes a conditional".

[kevina]

Well I still prefer the syntax of the ?: operator. I find your choice of formatting too verbose, especially for the simple cases when if_true and if_false are a single expressions (as oppose to multiple statements ending in an expression).

Nevertheless, I won't object very strongly if the ?: operator is removed.

[marijnh]

I'm also using ?: all over the place, but I still think removing it would be a good idea -- it frees up two (!) ASCII sigils in our expression syntax. Think of all the other awesomely cryptic things we could do with them.

[kud1ing]

A non-cryptic use would be to allow them as part of the predicate name.
E.g. "empty?()" instead of "is_empty()".

[nikomatsakis]

@marijnh ++ :)

[graydon]

Personally I don't give a hoot. Igor argued for ternary back in https://mail.mozilla.org/pipermail/rust-dev/2010-November/000110.html

[marijnh]

This was done in pull req #1705.

[caitp]

    return parent.index_of(child_a) < offset_b ? -1 : 1

looks infinitely better than

    return if parent.index_of(child_a) < offset_b {
        -1 
    } else {
        1
    }

If we have to be pythony about this,

return -1 if parent.index_of(child_a) < offset_b else 1

would be much better.

[rkyoku]

I agree, I don't get it why it had to be removed... Please do not force Rust users to write unnecessarily heavy/verbose code, when such a common practice (ternary operator) exists in most if not all languages.

Anyway, it is done, but I just wanted to add my voice to those supporting a cleaner code style.

[singpolyma]

I also miss this syntax

[loveencounterflow]

I think there are three conspiring effects at work here, viz

1. "The great statement/expression split" (@BrendanEich);
2. Coercion of non-Booleans in Boolean contexts;
3. Even 'dynamic' languages don't commonly get 'dynamic syntax' (real macros) and 'dynamic semantics' (a la Python's from __future__ import division) these days.

(1) means that if ... then ... else ... is sth fundamentally different from ... ? ... : ..., which is an entirely dispensable distinction. There are edge cases like return, but overall the distinction is not needed.

(2) means that you can, in many languages, use arbitrary expressions as tests; this looks only convenient as long as you're still using your first language and gets annoying as soon as you start with your second. As pointed out above on this reddit discussion, it's not clear why an empty list should denote either false or true—just write if ( d.length == 0 ) ... and you gained so much clarity!

(3) means you're stuck with whatever the language committee gives you, and whatever that is, the language will likely be stuck with it until someone comes along, forks or rewrites the codebase and gives it a new name. It could be different; there could be languages that allow, say, use 'ternary conditions'; use 'empty lists are false';. There are precedents for that. Of course, a lot of things speak against such flexibility because you will always have to keep in mind those "deviation markers" and remember to copy them when you copy-and-paste program. OTOH if mere users could change language syntax and semantics easily and prepackage such practices into installable modules, that could greatly help in the evolution of the language.