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: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Thu, 10 Apr 2025 12:42:05 +0100
Organization: A noiseless patient Spider
Lines: 141
Message-ID: <vt8aqd$2u21g$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 13:42:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d4d34b1d7ed35db6137f2b3fedef19a1";
	logging-data="3082288"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Z8vXelix2DSyhjYBJ+7WD"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:R8hbvpwm0EErPju8znP8Bqo1MSQ=
Content-Language: en-GB
In-Reply-To: <vt7te4$2hqe0$1@dont-email.me>
Bytes: 7159

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.

Here's a simple example where the function officially takes 4 
parameters, but I provide only what is relevant:

   MessageBoxA(message:"Hello")

It produces this:

  https://github.com/sal55/langs/blob/master/hello.png

One of the defaults is for the pop-up caption, as can be seen. Otherwise 
you can add 'caption:"Title"' for example.


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

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


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

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

(And where I use ':', but I have also used '=': 'a = 10' is a named 
argument and I'm passing 10, but '(a = 10)' is a positional argument 
where I'm passing 1 or 0.)

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

> 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). But it would need defaults added to make it useful:

HWND CreateWindowExA(
   [in]           DWORD     dwExStyle,
   [in, optional] LPCSTR    lpClassName,
   [in, optional] LPCSTR    lpWindowName,
   [in]           DWORD     dwStyle,
   [in]           int       X,
   [in]           int       Y,
   [in]           int       nWidth,
   [in]           int       nHeight,
   [in, optional] HWND      hWndParent,
   [in, optional] HMENU     hMenu,
   [in, optional] HINSTANCE hInstance,
   [in, optional] LPVOID    lpParam
);

Here, some optional args are indicated, but default values could be 
applied to several more, enough that a minimal invocation might need no 
arguments at all:

    hwnd = CreateWindowExA();