I see no semantical difference between
if(expr1) expr2 else expr3;
and expr1 ? expr2 : expr3;
Okay you need to learn the syntax, but it should be second nature after a few times. I also think the question mark is very intuitive.If-Then-Else is a statement. It doesn't return a value. It's just a branching operation between the two blocks.
The conditional operator is an expression. It returns a value hence it has a type. And that's where things start to be messy. Typing rules for the conditional operator are, well, not trivial and varie from language to language. Let's use an exemple from Java Puzzlers (Joshua Bloch and Neal Gafter) :
char x = 'X'; int i = 0; System.out.print(true ? x : 0); System.out.print(false ? i : x);
will print X88 but the same thing in C++
char x = 'X';
int i = 0;
cout << (true ? x : 0);
cout << (false ? i : x);
will print 8888.And I am not even talking about the priority mess when you try to use a conditional operator in a conditional operator.
You could expose the same semantic difference your example relies on with overload resolution, without needing to refer to the ternary operator at all. But I hope you wouldn't take that to mean that overloads are also a bad idea.
I also believe that the ternary operator is particularly nice when used in combination:
x = a ? foo :
b ? bar :
c ? baz :
blah;
The idiom tastes a little like pattern matching. Of course, you need to be a little cautious about your precedence, but I've never used a language supporting infix operators that didn't have gotchas around precedence.As for the priority mess, I spend my brain cycles elsewhere and use parentheses, which also helps the next guy as well as me.
I never ever remotely said that. You are putting words in my mouth and I don't like it. I just rightfully pointed that there actually is a semantic difference between the two mentioned lines. I never implied using any of them was wrong. I didn't even emit a judgement of value on either construct.
Now, I don't have problem per see against the conditional operator. It's just not as simple as some people like to pretend and it makes your code depends on some non obvious and not broadly known language feature for what is usually a minimal gain. So, yes, I do tend to avoid it in anything which is going to end in the hand of others (in the same way I try to avoid any un-obvious language idiom as much as possible). It's like nested comprehensions in Python, the slightly shorter code produced is just not worth the added complexity.