Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Thu, 10 Apr 2025 13:47:42 -0500
Organization: A noiseless patient Spider
Lines: 237
Message-ID: <vt93rd$3jj8k$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> <vt7te4$2hqe0$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 20:49:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8f70f4e52e0b2b3200bcfbc145cead94";
	logging-data="3788052"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/72qv0powYxMSVO9MAVV0q2SAi2rmbucQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Xcjz+yL4SFc+BTtQ5qvb/22/eo4=
In-Reply-To: <vt7te4$2hqe0$1@dont-email.me>
Content-Language: en-US
Bytes: 11094

On 4/10/2025 2:53 AM, David Brown wrote:
> 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.
> 

My likely rule here:
If named arguments were used, the prototypes are required to match 
exactly (including names);
At least within a translation unit.

However, this would only apply to prototypes whose arguments have 
initializer values. So, those like in BartC's example would be 
unaffected (but, also, could not be used with names either).

In cases where prototypes differ between translation units, it would be 
implementation defined. Most likely, it would depend on what was in 
effect at the call-site of the function.


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

My thinking is that they would not change the behavior of existing 
functions or prototypes, but would incur new some rules when used.

If a named argument is used, then it needs to have an assigned value, 
even if 0.

Similarly, the initializer values would be required to be a compile-time 
constant (possibly with some additional limits relative to what is 
allowed for initializers for global variants, say only allowing for 
primitive literals but no compound literals nor taking the address of a 
variable or function).

If no initializer is used, it is a fixed argument, and by extension may 
not be used as a named argument.


So, for example:
   void foo1(float x, float y, float z);       //fine, traditional
   void foo2(float x, float y=0, float z=0);   //fine
   void foo3(float x, float y=0, float z);     //bad, not allowed
   void foo4(float x=0, float y, float z);     //bad, not allowed
   void foo5(float x=0, float y=0, float z=0);  //fine

Likewise:
   foo1(1,2,3);  //fine
   foo1(.x=1, .y=2, .z=3);  //bad, these are not named arguments

========== REMAINDER OF ARTICLE TRUNCATED ==========