Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!brl-adm!husc6!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language (was: Still more new operators)
Message-ID: <2718@mmintl.UUCP>
Date: 18 Feb 88 18:46:38 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT.
Lines: 55
Summary: Let's take things out first


Any serious effort to design a successor to C (which does not attempt to be
upward compatible) should first consider what should be taken out and/or
done differently.  Adding new things is secondary.

The first thing I would remove is the automatic conversion of arrays to
pointers.  This was an understandable mistake, but a mistake nevertheless.
Removing it clears the way for treating arrays as first class objects.  (A
consequence of this change is that "a[b]" is no longer definable as
"*(a + b)".  We still have that it is equivalent to "*(&a[0] + b)", but this
cannot, of course, be used as a definition.)

Second on the list is defaulting of variables.  An undeclared variable
should be an error, not an int.  Likewise for functions.  I would favor
mandating ANSI-style function prototypes.  (Except that the "f(void)"
construct would not be needed -- "f()" means a function with no arguments.)

Another thing that should go is the assumption that the unit of storage is
the byte.  The base unit of storage is the bit, and sizeof should return the
number of bits in the object.  This enables to treat objects smaller than a
byte as first class objects.

I would also like to do away with having control statements control single
statements.  For example, instead of writing "if (foo) {stmt1; stmt2;}" I
would write "if (foo) stmt1; stmt2; end;".  Likewise, I would rewrite the
"for" statement as "for <stmts> while (<exp>) next <stmts> do <stmts> end;".
The "while" and "do ... while" I would generalize to "loop <stmts> while
(<exp>) <stmts> end;".  In keeping with the spirit of C, we avoid
superfluous words, and keep the ones we do use short.

With these changes, the {} statement delimiters become much less useful.  I
would probably drop them, and add a "begin ... end;" construct for those
cases where a local declaration is desired.

Another shortcoming to be fixed is the automatic fallthrough for select
statements.  The default should be exit the statement when a new case is
encountered, with an option to fall through.  I don't much like the current
syntax, either.  In any event, the syntax should include specifying multiple
values for a case (what is now accomplished by "case a: case b:").

To get even more radical -- with typedefs, enums, const declarations, and
(if we add them) inline functions, do we really need the pre-processor any
more?  Some kind of include statement should be provided, of course.  Any
decent compiler will optimize "const int foo = 1; if (foo) ... else ...
end;", so preprocessor conditional compilation is hardly necessary.

I would omit the automatic insertion of a null byte at the end of character
constants.  If you want nul terminated strings, write the nul.  If you want
strings with counts, the language should not get in your way.

I think I would also drop the convention that 0 is a null pointer.  Make
"null" a keyword, representing a null pointer of any type.
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108