in C and C++, the conditional statement is written using if and else, while the conditional expression is written with a ternary operator ? and :.
ending a sentence with . is a must. Including a period directly after a syntactic construct about ? and : is .. jarring because it is possible to attempt to read this as :. as an atomic construct in the language. Or even worse, the three-dots pyramid in some mathematical proof notations.
In C++, the lexical construct you describe is an atomic operator[0] and neither an expression nor a statement:
The first operand of the conditional operator is
evaluated and contextually converted to bool.
After both the value evaluation and all side effects
of the first operand are completed, if the result
was true, the second operand is evaluated. If the
result was false, the third operand is evaluated.
ternary(condition, true-path, false-path)
Lexing bleeds into syntax and syntax bleeds into semantics.
:. is a possible faux-pas in lexing the sentence around the ?...: construct because of :. being unfortunate.
I see that now. When I was composing my comment, they were there which is why they were quoted.
My apologies for how the response timing transpired.
I don't think "operator in syntax terms" is nearly as well-defined as OP thinks. Why couldn't `?` be parsed as half an operator and `:` as the other half? There's no rule that says a parser has to call each distinct symbol token its own "operator". In fact, I'd argue that the only reason this might seem seem like a rule is that almost all of the other operators in common use are either unary or binary, making it easy to use a single token for the operator itself. That's why it's called the "ternary operator"; it's the only one that operates on three things! The only alternative to spreading it out across separate tokens with an operand in between is to put multiple operands in a row on one side of it; as confusing as `foo ? bar : baz` might be, I have strong doubts that `foo ?: bar baz` would be less confusing in most real-world cases.
Because the language defines it to be an atomic operator named "conditional operator." As to the implications of that definition, please read the referenced link[0].
> In fact, I'd argue that the only reason this might seem seem like a rule is that almost all of the other operators in common use are either unary or binary, making it easy to use a single token for the operator itself.
It is "a rule" because that is how the language is defined. If you'd like to argue otherwise, please feel free to do so with the C++ standards committee.
0 - https://en.cppreference.com/w/cpp/language/operator_other
Thanks for the feedback!