Path: utzoo!attcan!uunet!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c
Subject: Re: Assignment in test: OK?
Message-ID: <4641:Sep1919:49:5990@kramden.acf.nyu.edu>
Date: 19 Sep 90 19:49:59 GMT
References: <1990Sep12.194753.9808@laguna.ccsf.caltech.edu> <14316:Sep1511:00:2390@kramden.acf.nyu.edu> <859@jonlab.UUCP>
Organization: IR
Lines: 29

In article <859@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes:
> BTW Dan, I think it should be yield, or evaluate to, a value, not
>          return a value.

Not if you don't distinguish between operators and functions.

> One of the many virtues of C is that assignment IS an operator and
> DOES yield a value.

Right. That's why you need to preserve that function, as :=. But
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).

> This part of the language is not broken, don't try to fix it.

You're taking entirely the wrong attitude. If beginners slip up
regularly on a language feature, and there's a straightforward way to
change the feature, then the feature should be changed (at least in
future languages). Just because you and I don't make a particular
mistake doesn't mean the language shouldn't prevent the mistake.

Furthermore, =/:=/== has an important benefit: The code-checker no
longer needs to special-case a = b when it's looking for ignored values.

The distinction between = and := is entirely logical, would eliminate
one source of frustration everywhere, and helps the compiler. What more
do you want?

---Dan