Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Thu, 10 Apr 2025 09:53:40 +0200
Organization: A noiseless patient Spider
Lines: 133
Message-ID: <vt7te4$2hqe0$1@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me>
 <vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me>
 <vsjg6t$20pdb$1@dont-email.me> <vsjgjn$1v1n4$1@dont-email.me>
 <vsjk4k$24q5m$1@dont-email.me> <vsjlcp$230a5$1@dont-email.me>
 <vsjmdl$277bk$1@dont-email.me> <VsdHP.1828827$TBhc.1078002@fx16.iad>
 <vskjlo$34st8$1@dont-email.me> <20250402220614.431@kylheku.com>
 <85mscxlqnb.fsf@nosuchdomain.example.com> <vsl9sn$3vdjj$2@dont-email.me>
 <20250403121946.134@kylheku.com> <vsms75$1i8ud$1@dont-email.me>
 <vsnhq6$291i3$4@dont-email.me> <20250409124900.00000fa1@yahoo.com>
 <vt5r34$inuo$7@dont-email.me> <vt6an7$13tvo$1@dont-email.me>
 <vt6gp0$16ejo$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 10 Apr 2025 09:53:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d51e7b029d04c4630234dc8501376c73";
	logging-data="2681280"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19B3iecx2tS1sfZzAk7dwHc61QmQmvukWo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:386wiPpowxYNKU8LBUS4dSGAFPU=
In-Reply-To: <vt6gp0$16ejo$1@dont-email.me>
Content-Language: en-GB
Bytes: 6842

On 09/04/2025 21:11, bart wrote:
> On 09/04/2025 18:26, BGB wrote:
>> On 4/9/2025 8:01 AM, David Brown wrote:
>>> On 09/04/2025 11:49, Michael S wrote:
>>>> On Fri, 4 Apr 2025 02:57:10 -0000 (UTC)
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>>> On Thu, 3 Apr 2025 21:48:40 +0100, bart wrote:
>>>>>
>>>>>> Commas are overwhelmingly used to separate list elements in
>>>>>> programming languages.
>>>>>
>>>>> Not just separate, but terminate.
>>>>
>>>> I disagree. I am in favor of optional trailing commas rather than
>>>> mandatory ones.
>>>
>>> I am certainly in favour of them for things like initialiser lists 
>>> and enum declarations.
>>>
>>>>
>>>>> All the reasonable languages allow
>>>>> trailing commas.
>>>>
>>>> Are your sure that C Standard does not allow trailing commas?
>>>> That is, they are obviously legal in initializer lists.
>>>> All compilers that I tried reject trailing comma in function calls.
>>>>
>>> ...
>>>> But is it (rejection) really required by the Standard? I don't know.
>>>>
>>>>
>>>
>>> Yes.  The syntax (in 6.5.2p1) is :
>>>
>>> postfix-expression:
>>>      ...
>>>      postfix-expression ( argument-expression-list opt )
>>>      ...
>>>
>>> argument-expression-list :
>>>      argument-expression
>>>      argument-expression-list , argument-expression
>>>
>>>
>>>
>>> I don't think it is unreasonable to suggest that it might be nice to 
>>> allow a trailing comma, at least in variadic function calls, but the 
>>> syntax of C does not allow it.
>>>
>>
>> Yeah, pretty much.
>>
>>
>> It might have also been interesting if C allowed optional named 
>> arguments:
>> int foo(int x=3, int y=4)
>> {
>>    return x+y;
>> }
>>
>> foo() => 7
>> foo(.y=2) => 5
>>
>> Likely would be following any fixed arguments (if present), and likely 
>> (for sake of implementation sanity) named arguments and varargs being 
>> mutually exclusive (alternative being that named arguments precede 
>> varargs if both are used).
>>
>> Well, at least ".y=val" as "y: val" likely wouldn't go over well even 
>> if it is what several other languages with this feature used (well or, 
>> "y=val", which is used in some others).
>>
>> In the most likely case, the named argument form would be transformed 
>> into the equivalent fixed argument form at compile time.
>>    So: "foo(.y=2)" would be functionally equivalent to "foo(3,2)".
> 
> There are all sorts of problems in adding this to C. For example, this 
> is legal:
> 
>    void F(int a, float b, char* c);
>    void F(int c, float a, char* b);
>    void F(int b, float c, char* a) {}
> 
> The sets of parameter names are all different (and that's in the same 
> file!); which is the official set?

C has had flexibility here for all sorts of reasons.  But if named 
parameters were to be added to the language without significant extra 
syntax, then this particular issue could be solved in at least two very 
simple ways.  Either say that named parameter syntax can only be used if 
all of the function's declarations in the translation unit have 
consistent naming, or say that the last declaration in scope is the one 
used.  (My guess would be that the later, with compilers offering 
warnings about the former.)

Of course that lets someone declare "void f(int a, int b);" in one file 
and "void f(int b, int a);" in a different one - but that does not 
noticeably change the kind of mixups already available to the 
undisciplined programmer, and it is completely eliminated by the 
standard practice of using shared headers for declarations.


> 
> Another is to do with defining default values (essential if named 
> arguments are to be fully used). First, similar thing to the above:
> 
>    void F(int a = x + y);
>    void F(int a = DEFAULT);
> 

Default arguments are most certainly not essential to make named 
parameters useful.  They /can/ be a nice thing to have, but they are 
merely icing on the cake.  Still, there is an obvious and C-friendly way 
to handle this too - the default values must be constant expressions.

A much clearer issue with a named parameter syntax like this is that 
something like "foo(b = 1, a = 2);" is already valid in C and means 
something significantly different.  You'd need a different syntax.

Fundamental matters such as this are best decided early in the design of 
a language, rather than bolted on afterwards.  Named parameters is 
something I like in languages, but it's not easy to add to established 
languages.

Still, the C++ crowd regularly try to figure out how named parameters 
could be added to C++.  I think they will figure it out eventually.  C++ 
adds a number of extra complications here that C does not have, but once 
they have a decent solution, C could probably adopt it.  Let C++ pave 
the way on new concepts, and C can copy the bits that suit once C++ has 
done the field testing - that's part of the C standard committee 
philosophy, and a good way to handle these things.