Should split-init be allowed for tuple declarations?

[mppf]

Today we support split-init for multiple-variable declarations:

var a, b, c;

a = 1;
b = 2;
c = 3;

writeln(a,b,c);

Should split-init also be supported for tuple declarations?

var (a, b, c);

a = 1;
b = 2;
c = 3;

writeln(a,b,c);

Today it produces an error like

error: use of 'tmp' before encountering its definition, type unknown

[bradcray]

I think we should support this, though I arrived at it in a roundabout way.

At first, I was thinking that it didn't really provide any value, so I didn't think I cared either way. Specifically, the typical benefit of the var (a, b, c) declaration form is to de-tuple a tuple initializer like var (a, b, c) = my3Tuple;. In a split initialization case, this doesn't really hold up since the example in the OP doesn't use tuple initialization (so is equivalent to the var a, b, c; case), and writing an attempt to split initialize them using (a, b, c) = my3Tuple; is something that could be supported by the non-tuple declaration style like var a, b, c; just as well. So it didn't feel crucial / important to support, though if we did, nothing is lost either. If we didn't support it, obviously the error message should be better.

However, then it occurred to me that one reason to potentially support it would be for people who don't understand/remember the split initialization behavior (like me often, since it's subtle), who perhaps write:

var (a, b, c): (int, real, string);

expecting it to be default initialized here, and not realizing the subsequent assignments to a, b, and c should be interpreted as initializations. To have such cases result in errors and require them to be rewritten as:

var a: int, b: real, c: string;

or by forcing the default initialization:

var (a, b, c): (int, real, string);
a; b; c; // force default init

or make it explicit:

var (a, b, c): (int, real, string) = (1, 2.3, "four");

seems counter to productivity (particularly if the code is changing in ways that flip back and forth between split init and default init based on code changes between the declaration and initial assignments). So that suggests to me that we should definitely support it.

Other issues seemingly related to tuples and split initialization, which suggest to me that this part of the code needs bolstering:

#19159
#17196
#16937
#16086

and possibly

#15700
#17050