What should be added to C

[Gregory Smith]

In article <5498 at alice.uUCp> ark at alice.UucP (Andrew Koenig) writes:
>> 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?

Just like i += x;:
	i /\= j;	means if( j>i ) i=j; ( very common )

>> 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.
>
>Why would you want to use it?

When your macro won't fit on a line, and/or you want to use #if's etc
as part of the macro, obviously. To fully support this, you'd want
to add #ifsame <arg1> <arg2>, and things like that, like MACRO-11's
assembler macros. How about #rpt n, and #irp SYM,list ? I don't think
the current cpp is doing enough to justify it being a seperate pass.
( although I would rather see its role given to the compiler, via
constant types, etc. `if(con_exp){..}' could be ignored if con_exp == 0, etc.)

>
>> o A typeof operator, similar to sizeof.
>
>What would its value be?  Why would you want to use it?
>
	x = (typeof x ) malloc ( n * sizeof( *x ));
			
>> o := as a synonym for =.  Compilers could have an option to permit := only.
>
>Why bother?
	ever write
		if( x=2 ){ ...
	????
I like this idea a lot.
>
>
>> o Any sort of multi-level break statement.  There is no syntacticly clean
>> way of adding this to C.
	break;	break 2; break 3;	break [con_exp];
>
>C already has a multi-level break statement.  It's spelled "goto."
>Putting a goto in a costume doesn't disguise it.
>
When a human reading a program sees 'break', it is immediately known
that the current loop is being abandoned. In order to determine the
effect of a goto, you have to find its destination. If you don't
believe there is a big difference, try maintaining someone else's
BAS*C code sometime.

>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.

You're absolutely right. Let's all use K&R C only for the rest of time.
-- 
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg