Defending the ternary operator

[Bengt Richter]

On Sat, 08 Feb 2003 18:56:54 +0100, Laura Creighton <lac at strakt.com> wrote:

>> Laura> Because I am one.  Because I know so many of them.  Because
>> Laura> 'lazy work' and 'hurried work' has been the bane of all
>> Laura> creators since we first started creating anything.
>> 
[Andrew Koenig]
>> As an experiment, I went back through a 2800-line C program that I
>> wrote about 20 years ago (!) to see how often I used ?: and in what
>> context.  I figure that reading my own 20-year-old code is probably a
>> lot like reading some else's code.
>
>The fact that you would not abuse a ternary does nothing to put my
>mind at rest.  I've wished for a world where all the C and C++
>programs I have encountered have been written by you, many times,
>sometimes in those exact words, as well.
>
>If you don't think that it will be used very often, do you admit that it
>might be on the side of 'diminishing returns', a feature request that
>doesn't 'pull enough weight' to be worth doing?  Or do you think that any
>language feature that is of use to somebody should automatically go into
>a language to 'add desired functionality'?  I doubt very much that you
>believe this, (though if you do, we have found the disagreement, for
>certain).  How do you determine if a proposed language feature 'pulls
>enough weight'? 
>
My immediate reaction is that philosophy enters into this.
We often hear "you can do it now" when someone asks for a feature,
and this is the case for the ternary. The functionality can be hacked
or rearranged. So it becomes a question of whether it is worthwile to
introduce another choice that might be more concise and robust than
existing choices.

If the introduction were cost-free, it would be a no-brainer. But the
costs and benefits include matters of taste and vary across phases of
development and maintenance and training, etc.

Philosophically, I would rather have a core of simple powerful primitives that
allows me to build a special feature than have a potpourri of everyone's pet
features built in. (The flip side of that is that abuse is easy and tempting).

But how "special" is special? We have seen some evidence that the ternary
is involved in less than 1% of C source code lines. That's pretty special,
so you would want a benefit that was pretty special, unless the feature's
availability was just a natural side effect of doing something "right."

ISTM we also have two stylistic motives that can pull in opposite directions.
I.e., programs as mnemonic narratives of decision/action sequences vs. programs
as algorithms best expressed with something resembling mathematical notation.

IMO both styles are needed, because neither style is always best. ISTM much
of the discussion re the ternary operator reflects preference for one style
or the other. If we have to choose one style, which is most appropriate to
the expression contexts where it will be used?

I confess to preferring mathematical-style notation in expressions.
I just had another idea ;-)
Maybe a variation on Paul's (IIRC) [cond -> expr; cond2 -> expr2; True -> expr3]
using '><' instead of ';' e.g.,

    cond -> exprT >< cond2 -> expr2 >< True -> exprF 

with a redundant final True condition and its '><' introducer being optional, e.g.
the basic ternary would pare down to:

    cond -> exprT -> exprF 
    
this could also have a default exprF if exprT is not followed by >< or ->.
What the default should be is another matter ;-)

Regards,
Bengt Richter