Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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 15:06:40 +0200
Organization: A noiseless patient Spider
Lines: 188
Message-ID: <vt8fp0$2vn84$2@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>
 <vt8aqd$2u21g$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 15:06:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d51e7b029d04c4630234dc8501376c73";
	logging-data="3136772"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/kQ3QVVsAvwprh3kgMwGuCSur35bbVZqQ="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:iNni38xfPqW6ZSey5wtatP3TFdU=
In-Reply-To: <vt8aqd$2u21g$1@dont-email.me>
Content-Language: en-GB
Bytes: 9170

On 10/04/2025 13:42, bart wrote:
> On 10/04/2025 08:53, David Brown wrote:
>> On 09/04/2025 21:11, bart wrote:
>>> On 09/04/2025 18:26, BGB wrote:
> 
>>>> 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.
> 
> Then the advantage is minimal. They are useful when there are lots of 
> parameters, where only a few are essential, and the rest are various 
> options.

That is one use-case, yes.  Generally, functions with large numbers of 
parameters are frowned upon anyway - there are typically better ways to 
handle such things.

Where named parameters shine is when you have a few parameters that have 
the same type.  "void control_leds(bool red, bool green, bool blue);". 
There are a variety of ways you can make a function like this in a 
clearer or safer way in C, but it requires a fair amount of extra 
boilerplate code (to define enum types for simple clarity, or struct 
types for greater safety).  Named parameters would make such functions 
safer and clearer in a simple way.

> 
>> 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.
> 
> Well, the most common default value is 0. But do you mean actual 
> literals, or can you use macro or enum names?

I mean actual constant expressions, as C defines them.  That includes 
constants (now called "literals" in C23), constant expressions (such as 
"2 * 10"), enumeration constants, and constexpr constants (in C23). 
Basically, things that you could use for initialisation of a variable at 
file scope.

> 
> Because it is those name resolutions that are the problem, not whether 
> the result is a compile-time constant expression.
> 

I don't see that at all.

> 
>> 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.
> 
> Not really; the above is inside a formal parameter list, where '=' has 
> no special meaning.

That is exactly the point - "=" has no special meaning inside a function 
call.  It is an assignment operator:

	int a = 10;
	int b = 20;
	int c = foo(b = 1, a = 2);

means the same (ignoring possible sequencing and ordering issues) as :

	int a = 10;
	int b = 20;
	b = 1;
	a = 2;
	int c = foo(b, a);


> 
> It is in an actual function call where using '=' is troublesome.

Yes - that's what we have been talking about.  Named parameters are used 
at the call site, not the declaration site.

> 
> Anyway in C you'd probably use '.a = 10' to align it with struct 
> initialisers, also that's a bit cluttery.

That does seem the most likely choice.

> 
>> Fundamental matters such as this are best decided early in the design 
>> of a language, rather than bolted on afterwards.
> 
> The funny thing is that my MessageBox example is a C function exported 
> by WinAPI, and I was able to superimpose keyword arguments on top. Since 
> I have to write my own bindings to such functions anyway.
> 
> The MS docs for WinAPI do tend to show function declarations with fully 
> named parameters, which also seem to be retained in gcc's windows.h (but 
> not in my cut-down one). 

gcc does not have a "windows.h".  You are conflating gcc with some 
windows packaging of gcc with additional tools, libraries and headers.

Personally, I think it is always good to give clear parameter names in 
function declarations.  There are reasons for not doing so (such as the 
possibility of some user defining a macro "lpClassName" before including 
the header file), but generally it keeps things clearer.  It is also 
particularly useful for library headers if they are used to generate 
interfaces for other languages.

> But it would need defaults added to make it 
> useful:

Strangely, many people have been able to write code using the MS API 
without named parameters or defaults.

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