Re: "A diagram of C23 basic types"

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();