On Thursday, 3 September 2015 at 17:15:25 UTC, Enamex wrote:
On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei
Alexandrescu wrote:
we should disallow during tokenization the sequence "=", "+",
whitespace. Surely it's not a formatting anyone would aim for,
but instead a misspelling of +=.
Wasn't the original design for these operators in whichever
language started them actually the swapped form? In any case,
I'd personally choose to warn against any operator sequence
without separating whitespaces if the sequence isn't in fact
one operator (like "=!" (non-warn: "= !") vs "!=", and "=&",
and a lot others, given operator overloading).
The += operator originally appeared in C, as the =+ operator
(K&R, 1/e, p212, "Anachronisms"). Not long afterward, the
ambiguity of a=+b became apparent, along with the obvious need to
change the language to resolve the problem. The issue was dealt
with over several successive releases of the compiler:
(1) =+ operator is available (original compiler)
(2) =+ and += are both available (I'm not sure whether this step
existed)
(3) =+ and += are both available; =+ produces a deprecation
warning
(4) += is available; =+ now produces either a warning/error or
just changes meaning, not sure which
I don't recall now where I read about that sequence of steps, and
a quick, incomplete scan of my library doesn't yield it up so I
could be more precise. Nonetheless, that's how the transition
happened. The Rationale for the original ANSI C (X3.159-1989)
mentions that =op forms have been dropped, and that in a Quiet
Change, "expressions of the form x=-3 change meaning with the
loss of the old-style assignment operators". Which I suppose
implies that the Standard itself doesn't require a warning
message, though presumably high-quality compilers would be free
to implement one.
K&R C did not contain a unary + operator (K&R, 1/e, p. 37,
Section 2.5). It was added by the first ANSI C, "for symmetry
with unary -" (K&R, 2/e, p204, Section A7.4.4). "An integral
operand undergoes integral promotion."
In terms of compiler quality, we have a long history of compilers
generating warning messages for legal but questionable
constructions. The first one that comes quickly to mind is GCC
complaining about "if(a=b)":
warning: suggest parentheses around assignment used as truth
value [-Wparentheses]
The notion here is that a common mistake is handled by:
(a) being warned about, when warnings are enabled (at least, by
-Wall in GCC)
(b) having an alternate construction suggested (e.g., "if((a=b))")
(c) having a specific compiler flag to control generation of each
such warning
