Issue 6365 - Multiple var declaration (AutoTupleDeclaration) #341

wants to merge 23 commits into


None yet
9rnsr commented Aug 27, 2011

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


    StorageClasses ( TupleTypeList ) = Initializer ;
    ( TupleTypeList ) = Initializer ;

    TupleType , TupleTypeList

    StorageClasses BasicType Declarator
    BasicType Declarator
    StorageClasses 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 commented Aug 27, 2011

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

(double x, int y) = fun();
9rnsr commented Aug 27, 2011

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 commented Nov 14, 2011

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?

@9rnsr 9rnsr closed this Nov 15, 2011
@9rnsr 9rnsr reopened this Nov 16, 2011
nazriel commented Jul 19, 2012

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

dsimcha commented Jul 19, 2012

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 commented Sep 9, 2012

Bump, any news on this?

nazriel commented Sep 9, 2012

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

dcousens commented Sep 9, 2012

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


Bump, bump, bump. Do want!

robik commented Sep 12, 2012

This is just awesome.

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

nazriel commented Sep 12, 2012

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

9rnsr commented Sep 13, 2012

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



@9rnsr 9rnsr referenced this pull request in dlang/ Sep 24, 2012

[enh] Documentation for Multiple variable declaration #160

meh commented Sep 24, 2012


9rnsr commented Sep 24, 2012

Documentation for this enhancement: dlang/


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 commented Sep 24, 2012

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.


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 commented Sep 24, 2012

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

ghost commented Sep 24, 2012

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


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.

AndrejMitrovic and others added some commits Dec 10, 2012
@AndrejMitrovic AndrejMitrovic Fixes Issue 9136 - Add isNested trait for aggregates and functions. 6ee244b
@9rnsr 9rnsr fix Issue 8902 - Unexpected "duplicate union initialization for X" error 840d88a
@yebblies yebblies Remove unused struct 'Environment' 1b7f937
@yebblies yebblies ddoc strings const correct 4d2aaa3
@yebblies yebblies Explicity take address of function 10b1ecd
@yebblies yebblies Don't take address of function without & fc89fa4
@yebblies yebblies Remove unimplemented method 001a936
@yebblies yebblies Copy-paste error 31129aa
@WalterBright WalterBright Merge pull request #1720 from yebblies/globalcopypaste
Copy-paste error
@WalterBright WalterBright Merge pull request #1719 from yebblies/unimpprop
Remove unimplemented method
@WalterBright WalterBright Merge pull request #1717 from yebblies/ddocconst
ddoc strings const correct
@WalterBright WalterBright Merge pull request #1715 from yebblies/removeenv
Remove unused struct 'Environment'
@WalterBright WalterBright Merge pull request #1718 from yebblies/takeaddress
Take address explicitly
@yebblies yebblies Merge pull request #1721 from AndrejMitrovic/Fix9635
Issue 9635 - Improve message on missing 'this' diagnostics.
@WalterBright WalterBright Merge pull request #1369 from 9rnsr/fix8902
Issue 8902 - Unexpected "duplicate union initialization for X" error
@MartinNowak MartinNowak Merge pull request #1362 from AndrejMitrovic/IsNestedTrait
Issue 9136 - Add isNested trait for aggregates and functions
@9rnsr 9rnsr Add TypeNone for type inference 5054891
@9rnsr 9rnsr isParameters now can check needId f035d61
@9rnsr 9rnsr Separate statement level and decldefs level cd6ece1
@9rnsr 9rnsr Update parser 12524be
@9rnsr 9rnsr Update initializer expansion process 3128f85
@9rnsr 9rnsr Add test cases 8e78e6d
@9rnsr 9rnsr Remove array expansion feature on initializer e748243
@9rnsr 9rnsr closed this Apr 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment