Supporting multiple initializations on the same line, x,y,z: float = 1,2,3;

[HALL9kv0]

I was playing around with cpp2 ans SFML and I had to initialize many variables of the same type, with different values. For example x,y,z speed, angle etc. So I ended up having 7+ lines of variable initializations with a repetition of the characters : float = .

I thought it would be much more concise and cleaner to have a single line of code like x,y,z,angle: float = 1,2,3,4; , similar to Go. It would be closer to how you would describe it: " I have variables x,y,z, angle of type float, which I initialize to values 1, 2,3,4". By extension this could be used in := and :const=.

I would like to know if others also think this is a nice feature to have. Sorry, if this has been suggested before, I searched for it but i didn't find anything.

[MaxSagebaum]

Personally, I do not declare multiple variables on the same line. I find it quite hard to read. This is also because pointer and reference declarations in C++ are right binding so int* a, b; declares a as a pointer and b as an int. Because of that I seldome use it and also advice against it.

Nevertheless, I can understand why this kind of syntax has its benefits. But for your proposed syntax the readability is not very great. Especially for a larger number of variables, the reader of the code has to count out the commas in or to know which variable is assigned to which value. Do you have any suggestion on how to address this issue?

If x,y,z,angle: float; is allowed then the initialization can be written as x = 1; y = 2; z = 3; angle = 4; This would be just two lines and much more readable.

[HALL9kv0]

I also never use it in C++ and I find it harder to read because the type is on the left and my mind reads int and doesn't know how many of them to expect . But in languages where the type is on the right like Go and cpp2, it just feels natural.

I think it's rare to declare very large number of variables of the same type on the same line, especially when the variable names are not just a letter. Even then, you can group them in separate lines for example based on context i.e

It's similar to the c++ structured binding, which was a great convenience when it came out in c++17.

x,y,z : float  = 1, 2, 3;  // position
vx, vy, vz : float = 4, 5, 6; // velocity
ax, ay, az : floatt =7, 8, 9 ;  // acceleration 

Other possible convenience: b, e : _ = vec.begin(), vec.end();

[hsutter]

x,y,z : float = 1, 2, 3; // position

Following @MaxSagebaum 's suggestion, note you can write this today which does half of what you want:

x,y,z : float;
x = 1; y = 2; z = 3;

You also have the flexibility of optionally doing other work between those initializations.

Does that help?

[bluetarpmedia]

note you can write this today which does half of what you want:

x,y,z : float;
x = 1; y = 2; z = 3;

I can't seem to get that to work on CE; I get this error:

error: invalid statement encountered inside a compound-statement (at ',')

[hsutter]

Oops, sorry, you are right -- I really don't know what I was thinking.

I am contemplating allowing multiple names in the future but have not implemented it, in part because I haven't yet decided whether I want to support only destructuring or also multiple actual objects (in which case destructuring would require parens or similar).

I shouldn't have replied while jet-lagged!

[hsutter]

I am contemplating allowing multiple names in the future but have not implemented it, in part because I haven't yet decided whether I want to support only destructuring or also multiple actual objects (in which case destructuring would require parens or similar).

I think the motivation for a destructuring syntax is strong, and the motivation for multiple variables of the same type feels much weaker:

• One feature of Cpp2 I really like is that "go to definition" is pretty much "search for identifier\s*:" (i.e., followed by optional whitespace and a colon), and this would defeat that (granted, so would allowing a similar syntax for structured bindings, but at least those would perforce always be local so finding definitions is much easier).
• I also really like that Cpp2 tries to keep to a single general basic declaration grammar. I don't think anyone would ever want to do multi-initialization for non-object declarations (e.g., functions, types, namespaces, or their aliases) so allowing that only for objects would create an asymmetry where you can put a comma-list of names on the left only for one kind of declaration.
• Even when all the names must have the same type, I worry that the syntax seems to quickly become hard to read when the initializer is more than a literal (e.g., even initializing three ints with three more complex expressions), especially for objects that require more complex initializers (e.g., multiple constructor parameters).
• Following the previous: I think it could not reasonably work for all single types, because one example that comes to mind is initializing a local variable with an unnamed function expression (lambda) or similar where the deduced type would be different for each initializer and so declaring multiple objects of the same type with initialization doesn't seem like it could work well (absent heroics like recognizing that case and forcing decay to function pointer, which would work for non-capturing lambdas, but then it still doesn't work for capturing lambdas).
• As languages like Go show, once you support multiple variables of the same type per declaration, the next thing people will ask for is multiple variables of different types.

So for now I don't want to support multiple declarations in the same statement, other than structured bindings which are on my todo list. And if I rule out multiple declarations in the same statement, then I can use that no-paren syntax at top for structured bindings.

[HALL9kv0]

I understand the reasoning behind not allowing multiple declarations/initialization in the same line, and I respect the decision. But once structured bindings are implemented, "single general basic declaration grammar" will not be a rule anymore. And furthermore, structured bindings will have the extremity of your last bullet point, since it will allow different types.

It would allow this like the following (A) :

x, y, z := someInitVariablesOfSameTypeFunc(1, 2, 3);  \\ or x,y,z : _ = ....
a, b, c := someInitVariablesOfDiffTypeFunc(1, "two", 3.0);

but not (B):

x, y, z : int  = 1, 2, 3;  
a, b, c := 1, "two", 3.0 ;

Which are essentially the same thing, but A has a "helper" function, which hides what actually happens.

Not saying that it would be a good practice to initialize 10 variables of 10 different types in one line, or use a "helper" function. There are cases though that for 2-3 simple variables this capability offers some convenience.

[hsutter]

Quick ack: Those are very reasonable points, thank you. In particular that any bindings would already allow multiple names on the lhs of declarations, for objects only.

[jcanizales]

There is an intrinsic difference in the language semantics between named things that can be created at runtime and named things that can only be created at compile time.

The former (objects, including lambda captures) are constructed by executing machine code, storing appropriate values in the corresponding memory. The latter (custom types, namespaces, function bodies) are constructed by interpreting the compiler's own special language for them (their syntax), which creates them in the compiler's memory (and part of which might end up in the final binary in some form).

It makes sense to me that the syntax for declaring and initializing things of either category might have to differ in some aspects. Even if for the most part it is kept consistent.

My favorite part of this project is the attempt to extend the "compiler DSL" with plain C++2 code that gets interpreted at compile time. One could think that opens the door for allowing destructuring initialization of things that aren't objects (fields, types, etc.). But the approach is to expose those things to the interpreted C++2 as objects (their reification), so the distinction remains.

[SebastianTroy]

I think that while structured bindings are useful, perhaps now is a good time to try to figure out a better solution? Structured bindings require auto type deduction, removing the ability to specify the type of a variable in a strongly typed language could be seen as a failure of the current language feature. Im not saying I have a better solution, but simply that we have a chance for some out of the box thinking here On 29 June 2024 02:39:57 Herb Sutter ***@***.***> wrote: Quick ack: Those are very reasonable points, thank you. In particular that any bindings would already allow multiple names on the lhs of declarations, for objects only. — Reply to this email directly, view it on GitHub<#1139 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQODR4POKQLVEWSW3WLZJYF6VAVCNFSM6AAAAABJYYNZE6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSMBZG44DQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[HALL9kv0]

removing the ability to specify the type of a variable in a strongly typed language could be seen as a failure of the current language feature.

We could retain the ability to strongly type the types in structured bindings if we allowed multiple same-line declarations for objects.

I think it boils down to 3 choices: Multiple comma-separated object identifiers allowed:

1. Only on the left of the :=

  a, b := stuctBindingA();  \\ (A) structured binding 
  c, d := 0;  \\ (B) multiple initializations with the same value 
  e, f: int; \\ (C) just declarations 
  g, h: int, int;  \\ (D) just declarations 

2. On the left and right of the :=

a, b := 1, 2;  \\ (A) multiple-inits 
a, b, c, d := stuctBindingA(), stuctBindingA();  \\ (B)  multiple structured bindings - Pretty much GO 

3. Neither on the left and right of the :=
The current status quo

In any of the cases 1 and 2, we should be able to explicitly declare the types next to : .
Based on my personal preference I would say that we need at lease cases 1.
Case 2(A) would be a nice convenience for certain situations, but I'm not a fun at all of case 2(B).
I think if case 2(A) is allowed, case 2(B) will eventually come up as a request.

[SebastianTroy]

Whatever the syntax is, it needs to work in for loops too, which use a : character, making typing structured bindings in a for loop awkward On 29 June 2024 15:27:01 HALL9kv0 ***@***.***> wrote: removing the ability to specify the type of a variable in a strongly typed language could be seen as a failure of the current language feature. We could retain the ability to strongly type the types in structured bindings if we allowed multiple same-line declarations for objects. I think it boils down to 3 choices: Multiple comma-separated object identifiers allowed: 1. Only on the left of the := a, b := stuctBindingA(); \\ (A) structured binding c, d := 0; \\ (B) multiple initializations with the same value e, f: int; \\ (C) just declarations g, h: int, int; \\ (D) just declarations 2. On the left and right of the := a, b := 1, 2; \\ (A) multiple-inits a, b, c, d := stuctBindingA(), stuctBindingA(); \\ (B) multiple structured bindings - Pretty much GO 3. Neither on the left and right of the := The current status quo In any of the cases 1 and 2, we should be able to explicitly declare the types next to : . Based on my personal preference I would say that we need at lease cases 1. Case 2(A) would be a nice convenience for certain situations, but I'm not a fun at all of case 2(B). I think if case 2(A) is allowed, case 2(B) will eventually come up as a request. — Reply to this email directly, view it on GitHub<#1139 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQNCSEJW4SI5QPCLOQTZJ273FAVCNFSM6AAAAABJYYNZE6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSMJSGM3TK>. You are receiving this because you commented.Message ID: ***@***.***>

[gregmarr]

This commit adds an explicit error for multiple inits on the same line. 8504e86

[hsutter]

Yes, and to clarify that doesn't mean I won't do the feature, the error message is just intended to make "why is this code rejected?" more understandable since I discovered people keep trying to write it now before it works. Example:

main: () = {
    x,y: int = 5;  // "error: declaring multiple names at once is not currently supported (at ',')"
}