Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: The D Programming Language: values and voids (was: == vs =)
Message-ID: <3290@haddock.ISC.COM>
Date: 1 Apr 88 20:39:02 GMT
References: <11216@brl-adm.ARPA> <2111@chinet.UUCP> <4403@garfield.UUCP> <931@micomvax.UUCP> <1011@mcgill-vision.UUCP> <956@micomvax.UUCP> <1390@eneevax.UUCP> <2794@mmintl.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 30

In article <2794@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
>The proposal [to make "a=b" a void expression and have "a:=b" take on the
>current assignment semantics] cleans up the semantics by eliminating the
>category of expressions with a non-void type whose value is commonly ignored.
>(Mostly -- there still may be functions returning values which are commonly
>ignored.)

Another case that remains is "++x" (or "x++") as a statement.  And the
compound assignment operators, unless you want to add "+:=" too.

The bit about functions is a problem; if the language were to be strict about
such sloppy return values, several specifications should be changed.  First
off, I'd distinguish an error-exit of a function from a return value (this
would clean up the "int getchar()" botch, too).  Then functions like printf()
should probably be void rather than int.  Now, strcpy() doesn't have an error
return; the reason it has a return value at all is best summarized as "Why
not?".  I would redo it as follows:

  char *_strcpy(char *s, char const *t) {
    while (*t != '\0') *s++ = *t++;
    return s;
  }
  void strcpy(char *s, char const *t) {
    *_strcpy(s, t) = '\0';
  }

Note that the first function returns the end pointer, not the start, and that
it does not store the NUL there.  (If you need access to the end pointer, you
probably have more stuff to write there anyway.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint