What should be added to C

[Davidsen]

I resisted commenting on the original or followup of this, but I can't
resist on this round!

In article <1497 at mmintl.UUCP> franka at mmintl.UUCP (Frank Adams) writes:
>In article <5498 at alice.uUCp> ark at alice.UUCP writes:
>>Frank Adams says:
...
>>> 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.
>>
>>What would it mean to use these on the left of an assignment,
>>and why would you want to use it?
>
>It would mean what it usually means.  If "\/" is the minimum operator, then
>"a \/= b" would mean "a = a \/ b".  I find it hard to believe that anyone
>with any programming experience would need to ask why you would want to use
>it.

Use of the <binary operator-assignment> feature is not the same thing
as "use left of assignment". The original request was poorly stated. As
for "most but not all C operators are", please state which binary
operator is not allowed to be used with assignment.

>>> o An andif clause for if statements.
>>
>>What does it do and how would you use it?
>
>You would write:
>
>  if (A) {
>    X
>  } andif (B) {
>    Y
>  } else {
>    Z
>  }
>
>This is equivalent to:
>
>   if (!(A)) goto _Z;
>   X
>   if (B) {
>     Y
>   } else {
>_Z:
>     Z
>   }

*you* might do that, but most people would nest the "if (B)" after the
"if (A)".

  if (A) {
    X
    if (B) {
      Y
    }
  } else {
    Z
  }

... discussion of #begdef deleted ...
>
>>> o A typeof operator, similar to sizeof.
>>
>>What would its value be?  Why would you want to use it?
>
>"typeof(x)" would be a type, which is the type that x was declared as.  This
>is for use primarily in macros.

I mentioned this to a number of people at the X3J11 meeting in Seattle.
It sounds neat, but is really pretty esoteric. Nobody could think of a
really great use for it, and trivial uses don't justify a change to the
language.

>>> o := as a synonym for =.  Compilers could have an option to permit := only.
>>
>>Why bother?
>
>Confusing "=" and "==" in if statements is a common mistake.  If "=" is not
>a legal operator, this error becomes very rare.

I once did this in a language called IMP (based on "B"), and it saved
no end of pain. However, I can't see changing the language to provide a
feature which can be provided by a preprocessor filter (I may even
write one now that the idea strikes).

>>> o Permit a continue statement in switch, meaning that the next label should
>>> be fallen through to.  Compilers and/or lint could produce when a program
>>> falls through without a continue statement.
>>
>>A continue statement is already legal in a switch, as long as that
>>switch is enclosed in a for or while.  It means go on to the next
>>iteration of the enclosing loop.  Are you proposing to change this?
>
>Yes.

You would break so many existing programs that you should wash your
mind out with soap for even thinking this. X3J11 was very careful to
make *additions* where appropriate, rather than break existing programs.

... discussion of multi-level break deleted ...

>>> o Elimination of the eight-character truncation of internal variable names
>>> done by some compilers.  (This may be in the current spec; I haven't read
>>> that document.)  The entire length of a variable name should be significant.
>>
>>Most compilers do this already.
>
>So let's make it part of the standard, and those of us who like to write
>portable code can start using it.

It is obvious that you haven't read the standard. The new length is 31
characters for internal names. Using *all* characters would allow a
valid program which had identifiers longer than the addressing space of
some machines. X3J11 also limited the length of macros and number of
levels of #include, so that "real C" could be implemented on reasonable
sized machines.

... discussion of how wonderful standards are deleted ...
>
>Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
>Multimate International    52 Oakland Ave North    E. Hartford, CT 06108

I believe the original posting also mentioned complex as a type,
currently in C++, desirable in C. Larry Rossler suggested that in an
early X3J11 meeting, but the response was underwhelming from most of
the committee. I personally feel that (a) this would get FORTRAN out of
my life at last, and (b) no one can convince me that it's too big,
since I had complex in FORTRAN on my CP/M machine with a total of 48k.
If there is a followup C committee for "C90" or whatever, I hope to be
able to participate again.

Disclaimer: if I have misquoted anyone on the X3J11 committee or failed
to quote them, the fault is mine.
-- 
	-bill davidsen

  ihnp4!seismo!rochester!steinmetz!--\
                                       \
                    unirot ------------->---> crdos1!davidsen
                                       /
         sixhub ---------------------/        (davidsen at ge-crd.ARPA)

"Stupidity, like virtue, is its own reward"