Re: "A diagram of C23 basic types"

On 4/10/2025 2:53 AM, David Brown wrote:

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.
 

My likely rule here:
If named arguments were used, the prototypes are required to match exactly (including names);
At least within a translation unit.
However, this would only apply to prototypes whose arguments have initializer values. So, those like in BartC's example would be unaffected (but, also, could not be used with names either).
In cases where prototypes differ between translation units, it would be implementation defined. Most likely, it would depend on what was in effect at the call-site of the function.

 

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

My thinking is that they would not change the behavior of existing functions or prototypes, but would incur new some rules when used.
If a named argument is used, then it needs to have an assigned value, even if 0.
Similarly, the initializer values would be required to be a compile-time constant (possibly with some additional limits relative to what is allowed for initializers for global variants, say only allowing for primitive literals but no compound literals nor taking the address of a variable or function).
If no initializer is used, it is a fixed argument, and by extension may not be used as a named argument.
So, for example:
   void foo1(float x, float y, float z);       //fine, traditional
   void foo2(float x, float y=0, float z=0);   //fine
   void foo3(float x, float y=0, float z);     //bad, not allowed
   void foo4(float x=0, float y, float z);     //bad, not allowed
   void foo5(float x=0, float y=0, float z=0);  //fine
Likewise:
   foo1(1,2,3);  //fine
   foo1(.x=1, .y=2, .z=3);  //bad, these are not named arguments
   foo2(1, .y=2, .z=3);     //fine
   foo2(.x=1, .y=2, .z=3);  //bad, x is a fixed argument
   foo5(.x=1, .y=2, .z=3);  //fine
   foo5(1,2,3);             //maybe bad, 1
1: named arguments are to be named. But, maybe, using them as positional arguments will work and behave as-if the names were given, making it equivalent to the preceding.
IIRC, all this is similar to the behavior in C#.

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.
 

Possibly.
I was more thinking one could have them partly because they are a nice thing to have in some scenarios.
Whether or not they could be adapted to C++, dunno.
Personally I don't really use C++ much, and my compiler's support for it is pretty lacking. To what extent it supports C++ is mostly to what extent C++ overlaps C and BS2 (which, is a bit hit or miss, given BS2 uses a Java-like object model, sorta).
The BS2 model does differ slightly from Java though:
   Allows dynamic objects (like in ActionScript)
     New fields can be added dynamically per-object.
     Internally, it is still a Class/Instance object.
     But, has a hidden JS style object internally.
   It is possible for scope to be delegated through designated members.
     It is vaguely similar to the Self scoping model.
     But, only applies to what is visible at compile time.
The original BGBScript had allowed a fully mutable object scoping model (like in the Self language), however, this was rarely used directly; and was complex and expensive to support efficiently (and part of why this VM was abandoned, dealing with this stuff just got too complicated in terms of the implementation).
In BGBCC's BS support and in the rules for my BGBScript2 language, the scope handling is limited to what is visible at compile time. If an interpreted version of BS were revived, dunno.
To some extent, the namespace scoping can be seen as an instance of this, albeit with the "objects" only existing at compile time (something like C++'s "using namespace whatever;" effectively creating an implicit variable which delegates the scope for the current namespace "object" to another namespace "object").
This also differs from JavaScript which only allows for a single "prototype" ("__proto__") per object, and forms a simple DAG; rather than supporting a free-form graph with possible cycles being allowed (so, is arguably a much simpler model vs that used in Self).
...