Re: "A diagram of C23 basic types"

On 10/04/2025 14:06, David Brown wrote:

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.

It probably wouldn't be too much of a problem in C, since outside of a function, there is only one scope anyway. But it can be illustrated like this:
   enum {x=100};
   void F(int a = x);
   int main(void) {
       enum {x=200};
       void F(int a = x);
       F();
   }
What default value would be used for this call, 100 or 200? Or could there actually be two possible defaults for the same function?
Declaring functions inside another is uncommon. But you can do similar things at file scope with #define and #undef.
Or maybe the default value uses names defined in a header, but a different translation unit could use a different header, or it might just have a different expression anyway.
(I would disallow this:
    void F(int a, int b = a)
where the default value for 'b' is the parameter 'a'. That would be ill-defined and awkward to implement, plus you could have parameter defaulting to each other.)

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.

But that wasn't a function call! So you can use '=' in declaration, and perhaps '.' and '=' in  a call:
    void F(a = 0);
    F(.a = 77);

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.

Huh? Do you really want to go down that path of analysing exactly what gcc is and isn't? 'gcc' must be the most famous C compiler on the planet!
Yes we all know that 'gcc' /now/ stands for 'gnu compiler collection' or something, and that it is a driver program for a number of utilities. But this is a C group which has informally mentioned 'gcc' for decades across tens of thousands of posts, but you had to bring it up now?
Any viable C compiler that targets Windows, gcc included, needs to provide windows.h.

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.

Yes, and we know what such code looks like, with long chains of mysterious arguments, many of which are zeros or NULLS:
     hwnd = CreateWindowEx(
         0,
         szAppName,
         "Hello, world!",
         WS_OVERLAPPEDWINDOW|WS_VISIBLE,
         300,
         100,
         400,
         400,
         NULL,
         NULL,
         0,
         NULL);
Even without named arguments, just default values, but allowing trailing arguments only to be omitted, those last 4 arguments can be dropped.
(BTW I swapped those first two NULLs around; I guess you didn't notice!)

Let's not pretend that MS's API's are good examples of clear design! (And please don't bother picking other non-MS examples that are the same or worse.)

We all have to use libraries that other people have designed.