Assignment in test: OK?

[Dan Bernstein]

In article <4089 at rtifs1.UUCP> trt at rti.rti.org (Thomas Truscott) writes:
> > ... changing the common = to not return a value will not affect 99% of the
> > lines in a typical program, and it will catch the beginner's if (a = b).
> But it will not catch the beginner's (or my) if (a := b).

But you and the beginner will both use = almost all the time. := will
always stand out as a rare case.

> It will not catch:
> 	if (a == b && c == d)
> 		a == b + 3;

Gee. My q2c translator spews out ``q2c: warning: foo.q(5): value ignored''
for a mistake like that. Your point is?

You're right that a problem isn't really a problem if the compiler can
reasonably warn you about it. But how do you suppose a C compiler should
detect whether if (a = b) was intentional or not? If a programmer is used
to that style, he'll be flooded with pointless warnings and eventually
learn to ignore them entirely. In contrast, he'd use := consciously, and
never fall into the pschological trap of thinking ``if a equals b'' and
writing ``if (a = b)''.

> APPENDIX: A MORE SERIOUS SYNTAX PROBLEM THAN =/==
> 	n = x[i,j];

q2c: warning: foo.q(6): value ignored. (Note that Q's arrays are
quite different from C's.)

The point is that ``value ignored'' warnings should be right almost all
the time. The compiler shouldn't have to play this guessing game where
sometimes a value is used and sometimes it isn't.

To put it differently, the language should support enough features that
an ignored value could reasonably be fatal. (Language design principles
for the '90s.) With = alone, the programmer can't express the logical
distinction between a used x = y and an unused x = y. This lack of
expressiveness can be expected to cause problems.

---Dan