What should be added to C

[KW Heuer]

In article <1462 at mmintl.UUCP> mmintl!franka (Frank Adams) proposes:
>> o Min and max operators.  These would get used all over the place.  These
>> should be usable to the left of the assignment operator, as most but not all
>> C operators are.

In article <5498 at alice.uUCp> alice!ark responds:
>What would it mean to use these on the left of an assignment,
>and why would you want to use it?

I think he means that in addition to MIN and MAX there should be MIN= and MAX=
operators.  I think this is a good reason for making them operators rather than
functions.  "x MIN= y" is clearer than "if (x > y) x = y", since the latter can
easily be misread as "x MAX= y", besides being subject to side effects.

>> o An andif clause for if statements.
>
>What does it do and how would you use it?

More specifically, how does it differ from "&&"?

>> o The ability to define multi-line pre-processor macros, using #begdef and
>> #enddef statements.  #if and other conditionals in the body of the
>> definition would be evaluated when the macro was not interpreted, not when
>> it is encountered.

The m4 preprocessor already has this functionality, and more.  Of course, if
using C without UNIX(R), you may not have m4...

>> o A typeof operator, similar to sizeof.
>
>What would its value be?  Why would you want to use it?

Presumably "typeof(variable)" would be syntactically a dataype, so it's not
really appropriate to call this an "operator".  There's one obvious use,
"p = (typeof(*p) *)malloc(sizeof(*p))".  I guess you could also use it in
"#define swap(x,y) {typeof(x) temp; temp=x; x=y; y=temp;}".  I don't know
that either of these is very useful, though.

>> o := as a synonym for =.  Compilers could have an option to permit := only.

To help catch "=" vs. "==" errors?  Or just to make PASCAL users happy?  (And
then we could make "<>" a synonym for "!=", and ...)

>> o Permit a continue statement in switch [to denote fall-through].

I'll address this elsewhere.

>> o Any sort of multi-level break statement.

No!  If you have code that seems to require a multi-level break, you should
think some more about the problem you're trying to solve.  If it's really
necessary, use a goto.  (I very seldom use even a one-level break, except as
the unique exit point in a "for (;;)" loop when it's too far from either end
to conveniently convert it into a "while" or "do".)

>The trouble with adding new features to C is that there is a very
>strong incentive not to use them.  After all, any program that
>uses some new feature is only going to run on machines that support
>that feature.  I don't think I'm going to be using only one compiler
>for the rest of my life and would like to avoid changing my code
>every time the environment hiccups.

Does this mean you don't use enum, void, or struct assignment?  The
"best" solution is to add the features to the official definition of
the language, but avoid using them in your code until "all" machines
support those features.

>>exchange operator.  This one is quite frequently useful, and the
>>alternatives are ugly.

Taking into consideration how bad the alternatives are, it *might* be a
good idea to make this a builtin operator; perhaps ":=:".  Either Andy's
suggestion of a concurrent assignment operator (could this possibly be
made a variant of struct assignment?) or my ",," operator would be more
powerful, if you don't have to worry about side effects.  (How often do
you need "a[i++] SWAP a[j++]" anyway?)

>>I do not support the following:
>>
>>o ^^ for logical exclusive or.

I agree with you here.  If both sides are true booleans (value zero or
one), either "^" or "!=" will do.  If not, then the user can just use
the standard "cast to boolean", namely "... != 0".  There's no loss of
efficiency since that's exactly how the compiler evaluates an integer
in a boolean context, and it probably makes the code easier to read, too.

>>o Doing anything about the array/pointer relationship.  What we have now is
>>a mess, but any attempt to fix it will produce a worse mess, either in the
>>language or with existing code.

Well, the change from "=OP" to "OP=" also broke existing code, but was done
quite nicely by phasing it in slowly.  I think it's possible to implement
arrays cleanly and introduce the changes gradually, but it's questionable
whether this should be done to C.  One could instead create a new language
"D" (or "P" if you prefer that sequence), which fixes several problems in C
without trying to be syntactically a superset of it.  A C-to-D translation
program would be a big plus.

>>o A separate boolean data type (sigh).  This is a good thing to have in a
>>language, but not a good thing to add to C as it exists.

I'm not sure why not.  Assuming all the implicit int/bool conversions stay,
I think the only problems are (a) it isn't really necessary, and (b) it adds
a new reserved word (breaking any programs that use "typedef int bool"!).

>>o There should be an option to flag statements of the form if (v = e) ...
>>(Actually, I wouldn't be averse to a coding standard which forbade such
>>things, in favor of if (v = e, v) ...)

Urgh.  Are you talking about removing the assignment-has-a-value feature
completely, or a special case for "if (v = e)"?  (I always write this as
"if ((v = e) != 0)" to make it clear that I didn't mean "if (v == e)".)

Actually, the main argument in favor of valued assignment is to allow such
things as "while ((c = getchar()) != EOF)".  This really doesn't look so
bad with the unvalued assignment "while (c = getchar(), c != EOF), so it
may not be such a bad idea.

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
Wait until you see *my* complete list of ideas!