unary +

[KW Heuer]

In article <2323 at brl-smoke.ARPA> HARGED%ti-eg.csnet at CSNET-RELAY.ARPA writes:
>Folks, no two ways about it: "a + +(b + c)" looks very strange (it looks
>like a typographical error), particularly when it is *required* to
>accomplish what most people intuitively assume "a + (b + c)" will
>accomplish.  From a human factors standpoint, this proposal is a
>disaster.  If adopted, it will become a textbook example of an
>anti-intuitive language construct.  While it is important that compilers
>generate maximally optimized machine code, it is more important that
>humans be able to read and understand the source code.  This one has the
>potential to introduce some truly subtle bugs ("Oh!  There's supposed to
>be a space between the two plus-signs!"), as well as sow confusion among
>user's who are not intimately familiar with code generation.

(OOE = Order-Of-Evaluation.)

[0]  "+()" is a bad notation, no doubt about it.  If unary plus is to have
any meaning at all, it should be the obvious arithmetical no-op on real
numerical arguments.

[1]  "()" is worse.  The code generator should NOT have to assume all
parens specify OOE.  In the example given it looks intuitive (since I could
write "a+b+c" for dont-care, obviously "(a+b)+c" or "a+(b+c)" reflect
intended OOE), but it's not true in general.  Also, it's already been
observed that expanded macros often have extraneous parens.

[2]  The way to specifically disambiguate in the current standard is to use
an explicit temporary: "temp=b+c; a+temp".  I presume the reason for the
proposed unary plus operator is to remove the need for a declaration, and
to reduce the compiler's work.  (It's not easy for the compiler to know
that "temp=b+c; a+temp" can be reduced to "a+ +(b+c)", especially if the
same variable "temp" is used elsewhere for the same trick.)

[3]  Someone proposed using "a+(volatile)(b+c)".  I think this is workable,
though not quite the same meaning as volatile applied to a simple variable.

[4]  Finally, the most important point.  WHO THE HELL IS GOING TO USE SUCH
A FEATURE ANYWAY?  I have *never*, to my recollection, tried to force OOE,
nor seen any program that did (excluding the use of temporaries to control
the order of side effects, which is not addressed by the unary plus issue).
Given its extreme rarity, I think the "subtle bugs" and "confusion among
[unfamiliar] users" are irrelevant -- except that someone may make a typo
and accidentally invoke a unary plus.

The alleged reason for "=" being assignment rather than compare is that
assignment is used more often and deserves the shorter symbol.  (I might
believe this argument if they'd also applied it to "&&".)  In my opinion,
the OOE operation does not deserve a one-character symbol, nor a new
keyword.

I vote for [3], given the prior existence of an appropriate keyword.

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint