Issue 6365 - Multiple var declaration (AutoTupleDeclaration)

[9rnsr]

http://d.puremagic.com/issues/show_bug.cgi?id=6365

Based on #321, declare multiple variables at once, and initialize them in the corresponding tuple fields.

Syntax:

TupleDeclaration:
    StorageClasses ( TupleTypeList ) = Initializer ;
    ( TupleTypeList ) = Initializer ;

TupleTypeList:
    TupleType
    TupleType , TupleTypeList

TupleType:
    StorageClasses BasicType Declarator
    BasicType Declarator
    StorageClasses Identifier
    Identifier

TupleTypeList is similar to ForeachTypeList.

If you want to write left parenthesis at beginning, you cannot omit the type or storage class of first variable.

(x, y) = getCoordinate();  // NG, this is not multiple var declaration
(auto x, y) = getCoordinate();  // OK
(double x, y) = getCoordinate();  // OK, types are specified explicitly

[dsimcha]

What about functions that return multiple values of different types? Would this work?

(double x, int y) = fun();

[9rnsr]

Yes. In your case, fun() should return tuple type, and

(double x, int y) = fun();

is just translated to

auto __tup = fun();
double x = __tup[0];  // __tup[0] has a type that is implicitly convertible to double
int y = __tup[1];     // ditto

Therefore, fun() can return Tuple!(int, int) or Tuple!(double, int).

[dsimcha]

I love this idea. Is there any language design-level reason why it shouldn't be included or are we just waiting for Walter to get around to merging it?

[nazriel]

Bump, this is really sexy.
Same question as @dsimcha : Is there any language design-level reason why it shouldn't be included?

[dsimcha]

On looking at this again one concern I see is the implicit temporary. This is caused by creating __tup and would cause postblits to run an extra time in cases where structs are being copied. This may not matter, though, since we're trying to discourage designs where structs can be arbitrarily expensive to copy.

[Dav1dde]

Bump, any news on this?

[nazriel]

@WalterBright what ya think about this?
@9rnsr has done amazing job to make work with Tuples great experience!

[dcousens]

Bump, really looking forward to seeing this merged in. The simplicity of tuples is not going away :).

[jpraczyk]

Bump, bump, bump. Do want!

[robik]

This is just awesome.

I have a question, does it work on function declarations? Like public (int, int) getCoordinates() ?

[nazriel]

@robik I don't think so, but probably @9rnsr will know better

[9rnsr]

@robik Unfortunately, no. This enhancement just supports distributing tuple fields to each variables in initializing.
I think your implication is "returning multiple values from function without packing (like Tuple!(int, int))", and it is completely different thing. And it's hard to implement, because it requires ABI change.

[repeatedly]

LGTM 👍

[meh]

+1.

[9rnsr]

Documentation for this enhancement: dlang/dlang.org#160

[andralex]

Just to give a bit of feedback - we're looking into this. If we conclude that this language addition solves most of the issues with tuples (so no radical redesign is needed), we'll pull this in. We don't want to pull this thinking that it might hurt a better future design.

[9rnsr]

We don't want to pull this thinking that it might hurt a better future design.

What might be hurt in the future? Syntax? Semantics? or ABI issue?
I'd like to know that you worried in current.

[andralex]

Syntax and semantics mostly. Walter and I are worried about overarching design more than anything. Consider that the "perfect" tuples for D are six good design decisions away. This pull request deals with destructuring and makes one decision, which is shaping all future decisions. If we later conclude tuples need some additional form of destructuring, or something different entirely, we'll have to add that too. And then some other stuff on top of that. So instead of making one move at a time and then analyzing the result, we want to think the strategy forward so as to have a good overal design, not (only) a good design for destructuring.

Now, it's quite possible that destructuring is about all we need, or that whatever else we need doesn't interact badly with destructuring. In that case this request will be pulled, and everybody will be happy.

[9rnsr]

Thanks for your answer, @andralex . I cannot reply to your worry immediately, but I also would like to think about it.

[ghost]

I'd like to be able to ignore a return value if that's possible. For example

(int a, void) = fun() -> discards second value

That way I don't have to forcefully introduce new symbol names into the current scope (using _ is a nogo because there might already be such a symbol, e.g. in foreach loops or a previous tuple destruction).

[WalterBright]

I agree with Andrei, while I don't see anything obviously wrong with this proposal, I'd like to see a complete tuple design before committing ourselves to one aspect of it.