The D Programming Language (was: Still more new operators)

[Frank Adams]

In article <1988Feb25.202237.8688 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>> ... An undeclared variable should be an error, not an int.
>
>Um, perhaps you should learn C before you start designing D...?  An
>undeclared variable *is* an error.

Mea culpa.  The C compilers I use give warnings for undeclared functions and
several other things, which I treat as errors; so sometimes I forget which
ones are really errors.

The point still stands as regards undeclared functions, though.

>> 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.
>
>Here we have a key decision:  is D to share C's emphasis on generation
>of efficient code?

Yes.

>If so, then trying to forget that bytes exist is a serious
>mistake.  Most machines cannot handle bits with anywhere near the efficiency
>with which they handle bytes; the appropriate base unit for efficient code
>*is* the byte.

This makes C nicely efficient on *many* machines; but there are others on
which a larger size would be much better.  Not every machine is byte
addressable.

Conversely, on those machines which *do* have bit addressing, C provides
very inefficient access to it.

We need to figure out how to make D efficient without regard to the
addressing unit of the machine.  Off-hand, I'm not sure how to do that.

>> ... 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...
>
>Please explain how avoiding superfluous words and keeping necessary ones
>short is consistent with changing {/} to begin/end for no particular reason.

I was thinking that with the other changes I proposed, the compound
statement would be needed only for declaring variables local to part of a
function.  This use is not important enough to justify allocating two special
symbols to it.

This overlooks the compound statement forming the body of the function.  This
is easily enough dealt with by making the function syntax be:
	type declarator declarations statements end ;
instead of
	type declarator { declarations statements }

One possible use for the braces would be as type parentheses, so one could
write:
	{int *} a, b;
to make both a and b pointers to int.  I think using this for casts would
improve readability as well.  (That is, replace the parentheses around the
cast type with braces.)

This is an off-the-cuff idea, there may be better ones.

>> do we really need the pre-processor any more? ...
>
>The C++ people claim that the answer is "not much", given inline functions
>in particular.  They do still use it for some specialized problems, though.

Overall, the preprocessor seems to be used as a way to hack prototypes for
the next extension to the language.  C++ people tend to use it for
parameterized types, early C used it for consts and enums, etc.  This may be
an argument for keeping it.

>> 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.
>
>Pray tell, how do you write a counted-string constant?

struct string {char * data; int size};
char dummy[] = "This is my string."
struct string s = {&dummy, sizeof(dummy)};

If you want the length immediately preceding the string, you need new syntax
and/or the pre-processor to avoid writing the string twice.

>I would suggest that "abc" should mean a length-3 string with any necessary
>terminator, regardless of what flavor of string is in use.  That way you get
>a choice, without recoding all your string constants.

And how do you specify what flavor of string is "is use?".
-- 

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