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

On 17/08/2024 15:41, Tim Rentsch wrote:

Bart <bc@freeuk.com> writes:

OK.  So why do you agree with this:
>

                            C call-by-value         call-by-reference
                            ===============         =================
        (pointer argument)  F(p)                    (disallowed)

>
What is 'pointer argument' here?

 Try thinking harder.  Everyone else understood.

I could equally say that everyone understood what was meant by 'implicit cast'.
But here you really have to explain what you mean by a pointer argument, since there is no reason why such a type can't be passed by reference.
Lacking such an explanation, I'd have to say still that 'disallowed' is generally incorrect. Try harder with your arguments.
(I earlier toyed with a proposal to add by-reference parameters to C.
But I decided not to actually implement it to see how well it would; I was satisified that it probably would. (I've been doing this stuff a long time.)
Under that scheme, ANY parameter type can be passed by reference.
But it would be incompatible with C's array-decay behaviour. So currently:
   void F(int A[]) { A[i];}         // A has type int*
   int x[10]; F(x);                 // Passes &x[10] of type int*
It would be:
   void F(&int A[]) { A[i];}        // A has apparent type int[]
                                    // but is really int(*)[]
   int x[10]; F(x);                 // Apparently passes type int[10]
                                    // but really &x which is int(*)[10]
(A pointer to an array 10 should be compatible with a pointer to array 0.)
The advantage is better type-safety: you can only pass an actual array type and not the address of random integer. Neither can you pass NULL.
But no array-to-pointer decay happens with F(x) when F is by-ref, since it is really treated as F(&x).)