Re: technology discussion → does the world need a "new" C ?

On 11/07/2024 22:36, bart wrote:

On 11/07/2024 21:29, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

 

The language could have helped a little by making this invalid:
>
    int A[20];
>
    void F(int B[20]) {}
>
The type of B looks just like that of A, but it isn't; the T[N] type
is silently changed to T*. The language could insist that you write:
>
    void F(int* B) {}

>
But it doesn't.  Why should we waste time in comp.lang.c explaining how
C *could* have been defined?  It's hard enough to explain how it
actually is defined, especially with your contributions.
>

This way, it is far clearer that a pointer is being passed, and 'pass
by value' now makes more sense. The way B will be used is now
consistent with the same declaration anywhere else.

>
But that's not C.

 Why isn't it C?

Are you trying to blame us for how C is defined?  Or is this a serious question about the historical process of design decisions in C?  My only guess here - and it is only a guess - is it goes back to the way function parameters were written in K&R C before prototypes, and supported because in C, declarations follow usage.  You can write B[10] whether you have "int B[20]" or "int * B", so it seems natural that you could use either form when declaring the parameter.
(Note that I too would have preferred a different syntax.  IMHO it would have been better either to allow passing arrays by value in some way, or not to allow code that /looks/ like it passes arrays.)