Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: technology discussion =?utf-8?Q?=E2=86=92?= does the world need
 a "new" C ?
Date: Thu, 11 Jul 2024 13:29:18 -0700
Organization: None to speak of
Lines: 100
Message-ID: <87frsfu0yp.fsf@nosuchdomain.example.com>
References: <v66eci$2qeee$1@dont-email.me> <v6gl83$s72a$1@dont-email.me>
	<v6h8ao$ur1v$1@dont-email.me> <v6jhk3$1drd6$1@dont-email.me>
	<v6jiud$1dsjb$1@dont-email.me> <877cdur1z9.fsf@bsb.me.uk>
	<v6joi4$1epoj$1@dont-email.me> <871q42qy33.fsf@bsb.me.uk>
	<v6k6i0$1h4d3$1@dont-email.me> <87ed82p28y.fsf@bsb.me.uk>
	<v6m03l$1tf05$1@dont-email.me> <87r0c1nzjj.fsf@bsb.me.uk>
	<v6m716$1urj4$1@dont-email.me> <86ikxd8czu.fsf@linuxsc.com>
	<v6mggd$20g3f$1@dont-email.me> <20240710213910.00000afd@yahoo.com>
	<v6mm02$21cpb$1@dont-email.me> <865xtc87yo.fsf@linuxsc.com>
	<v6ol14$2fdrj$1@dont-email.me>
	<87msmnu5e3.fsf@nosuchdomain.example.com>
	<v6pdcf$2jijk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 11 Jul 2024 22:29:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c51c7f9518f437252e8df6d7af482dc8";
	logging-data="2744944"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX191BKOE7LjQ4zQBmiFNFzqp"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:g5CnHYe0j/PvLfwqkhEOuaGoCec=
	sha1:e8LKrun91W2/2DzRYp7e0pV9/ug=
Bytes: 5349

bart <bc@freeuk.com> writes:
> On 11/07/2024 19:53, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> For that purpose, in the mind of the user, it does the same job as 'by
>>> by reference'. That it does so by some other quirks (array decay, and
>>> the ability to index pointers as thought they were arrays), is by the
>>> by.
>> [...]
>> Those "quirks" are a rich source of confusion and bugs for anyone
>> who
>> doesn't understand how this stuff is actually defined.  (Yes, I'm
>> acknowledging, yet again, that the way C specifies its treatment of
>> arrays is confusing.)
>> A user who thinks that arrays are simply "passed by reference" is
>> likely
>> to try to apply sizeof to an array parameter (and might or might not get
>> a diagnostic from the compiler).  A slightly more sophisticated user is
>> still likely to be unsure of just where the "quirks" are.
>> What have you ever done to help make that kind of error less likely?
>> What is your goal?
>
>
> This my first comment on the subject:
>
> "Arrays are passed by reference:
>   ...
> Although ..."

And that statement was incorrect, even with the "Although".

> (Note that 'Although'.) And the first reply was:
>
> BB:
> "All parameter passing in C is by value.  All of it."

Which is a correct statement.

> And there's been no let up since then.

Because you keep insisting on your confusing and incorrect explanations
of how arrays work in C.

> Nobody has acknowledged that there's more going on with passing array
> types than it simply being due to 'pass by value', if it's not full
> 'pass by reference'.

Nonsense.  We've repeatedly explained that parameters of array type are
really of pointer type, and that expressions of array type are usually
converted to pointer expressions, and the exact contexts in which that
does or does not occur.  That is exactly the "more going on" that you
claim we're hiding.

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

> My goals might be to make the language a little more accessible,
> although that cuts little ice here where most are C experts of long
> standing; they won't know or will have forgotten what it's like to be
> a beginner or outsider, or coming to C from saner languages.

Oh?  Are you proposing a change to C, perhaps for the 2026 edition of
the C standard?  Have you designed your changes, and made sure they
don't quietly break existing code?

Or do you think that pretending C has pass-by-reference makes the
language "more accessible"?

You and I both know how arrays interact with function parameters and
arguments in C as it's actually defined.  Are you trying to hide that
knowledge from your readers?

> However I use /my/ saner language every day.

Good for you -- but why should anyone here care?

I was about to suggest that you can discuss it in comp.lang.misc, which
seems to be reasonably active, but I see you've already posted there.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */