Re: "A diagram of C23 basic types"

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.

 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.
Still, the C++ crowd regularly try to figure out how named parameters could be added to C++.  I think they will figure it out eventually.  C++ adds a number of extra complications here that C does not have, but once they have a decent solution, C could probably adopt it.  Let C++ pave the way on new concepts, and C can copy the bits that suit once C++ has done the field testing - that's part of the C standard committee philosophy, and a good way to handle these things.