Gah.. I hate the ternary operator.

Not that it's necessarily a bad thing in and of itself, but every time I've come across it in code, I've ultimately had to yank it out because I've needed to support an additional possibility. I don't get what value it really supplies, and it seems like people are really fond of using it in the wrong places.

I don't get what value it really supplies, and it seems like people are really fond of using it in the wrong places.

It's a conditional expression , not a statement, and particularly helps simplify things like

    if(foo)
        someVeryVeryLongExpressionEvaluatingToAnLvalue = someShortRvalue;
    else
        someVeryVeryLongExpressionEvaluatingToAnLvalue = otherShortRvalue

into

    someVeryVeryLongExpressionEvaluatingToAnLvalue =
        foo ? someShortRvalue : otherShortRvalue;

I suppose to really "get" what the ternary is useful for, you have to have some experience with a more functional programming language, focusing on the flow of the data itself. There, multiply-nested ternaries are really the norm for what you'd otherwise call "control flow" in non-functional languages, and structures like this are common:

   value = isAtrue ? A_value :
           isBtrue ? B_value :
           isCtrue ? C_value :
                     D_value ;

(Does not work in PHP, but every other language with a ternary will interpret that as a compact alternative to the far more cumbersome if/else --- especially if coding standards dictate braces on their own line.)

I don't like the ternary operator ?, because it's not obvious:

xyz = foo ? bar : baz;

What does it mean? Which is the condition? which is the true, which is the false value? It's not obvious.

In Python it is much more clearer:

xyz = bar if foo else baz

I honestly struggle to understand how a traditional ternary like this isn't obvious. The bit before the question mark is the condition (er, like a question, which ends with a question mark), then the other two bits are for true and false in the order you would expect.

I will freely admit I try and avoid nested ternaries, which I personally find hard to read.

I never really understood the distaste for it, or how it’s non-obvious. It seems like the people I’ve talked to object to the punctuation-based syntax more than the semantics, because it exactly mirrors conditional statements, even when nested. (Well, except in PHP, but that’s a bug in the grammar.)

    if (a) { b } else   if (c) { d } else { e }
        a  ? b   :          c  ? d   :      e

    if (a) { b } else { if (c) { d } else { e } }
        a  ? b   :    (     c  ? d   :      e   )

The question mark goes after the thing you’re asking about, like in English. The colon to separate the true and false branches is totally arbitrary, I grant you. I’d prefer to have the if…else notation available as an expression, but the statement-expression distinction hasn’t quite died yet.

Personally, I don’t care for Python’s version with the condition and true branch swapped, because I read it like invalid Forth, expecting “condition IF true-branch ELSE false-branch THEN”. :P

The ternary operator can be nice for conciseness and to ensure a variable has been assigned to when the language doesn't check that for you e.g.

    var x = condition ? 1 : 2;

vs

    var x;
    if (condition)
      x = 1 
    else 
      x = 2

I miss being able to write code like this in languages like OCaml:

    let x =
      if (condition) then
        // more lines of code
        1
      else 
        2

Heh your OCaml example is why I adore Nim, and any other languages that "expression all the things!" -- even modern JavaScript is decent on this front with 'ramda' and my favourite helper library @unction: https://github.com/krainboltgreene/unction.js/blob/core/READ...

Between those two, consise readable functional JS code based entirely around expressions is simple to achieve. It's genuinely made me happy to be back in JS land

In C it's useful as it allows you to still const a variable when assigning a value conditionally.

  const int x = a ? 1 : 2;

I managed to go about 15 years without using the ternary operator. Pretty much the only time it's really good at what it does is for assignments, and I've started using it a bit myself.

However, the old discomforts come up pretty frequently. I find people slipping functions into both the right hand and left hand side. And once you do that, you really should push it into a new function. Especially if you have any plans for testing.

Most compilers are pretty good at inlining things like that, and at any rate there are almost always bigger performance problems than function call overhead. In fact, one of my big tricks is that a function that consists of a weird but fast algorithm is generally tolerated by your coworkers better than just dropping it into the middle of a block of code. And knowing they could easily revert the change (because it's only one commit and one function body!) if it starts to annoy them also helps.

tl;dr: Just like comments in the middle of a function reveal a missing function, a ternary operator probably means the same.

Or bitwise OR and XOR operators, according to the article? That's a bit hard to believe, no pun intended.

Bitwise OR and XOR are supported on ints. It doesn't work on bools, but there are equivalents: https://play.golang.org/p/GCAFwx03pi

Bitwise OR and XOR on bools. Bitwise XOR is just !=, so it's useless. Bitwise OR isn't identical to any other operators, but writing code which specifically relies on side-effects of a function on the RHS of an OR does not strike me as the sort of thing that the Go designers would approve of.

Bitwise OR is equivalent to addition, but IMHO it makes more sense to omit support for addition on bools than to omit support for the classical boolean operators supported by C++. If for no other reason than to make existing C++ code easier to port.

Addition on bools is XOR.

Not by C++'s convention. It may be compiler-dependent, but all of the compilers I have within easy reach treat addition of bools as an 'or' operation.

    bool a = true;
    bool b = true;
    bool c = a + b;

This leaves c set to true. Basically it gets promoted to int, turned into a value of 2, and demoted back to bool.

Either way it's highly nonstandard not to implement a bitwise-or operation on a boolean type. It's a violation of the "principle of least surprise" as well as a portability hazard. No upside that I can imagine.

I have been writing C for a while and never saw anyone add bools with +. Why do this when there is completely unambiguous || ?

I get suspicious of being fast and loose with conversions between int and bool. This is implicitly required when working with operators like &&, ||, ==, etc., and working with pre-C99 bools and library typedefs. But assigning anything other than 1 or 0 is asking for problems. There is a whole class of bugs that shows up in security bugs involving assigning someone's machine-word-sized Boolean expression into someone else's byte sized bool, losing bits, and flipping from true to false.

I sometimes feel there is a ^^ operator that should be there and is missing, in the same way that we have && and || corresponding to & and |. I have occasionally faked it with a macro:

    #define XOR(A,B) (((A) ? 1 : 0) ^ ((B) ? 1 : 0))

The ? here eliminates the problems from using larger != 1 quantities as true, as above.