tuple decomposition declarator

[gafter]

This feature would allow multiple names to be declared wherever a single identifier declares a variable today, and the type is statically known to be a tuple type. Those individual identifiers would refer to the members of the (anonymous) underlying tuple variable.

For example, if a method returns a tuple

    (int, int) M() => (1, 2);

then one could call this method, and receive the results into an anonymous local variable, whose elements can be referred to by simple names:

    var (x, y) = M();
    // following code can use x and y

one can think of var representing the type (int, int) in this example, and the declaration is of an anonymous local variable of that type, whose members are accessible as x and y. This is similar to the mechanism of transparent identifiers in the specification of the Linq expression forms.

Syntactically, this would be specified by introducing a declarator_id to be used in places that an identifier appears currently to define a variable.

declarator_id
    : identifier
    | '(' declarator_id ',' declarator_id_list ')'
    ;

declarator_id_list
    : declarator_id
    | declarator_id_list ',' declarator_id
    ;

local_variable_declarator
    : declarator_id
    | declarator_id '=' local_variable_initializer
    ;

foreach_statement
    : 'foreach' '(' local_variable_type declarator_id 'in' expression ')' embedded_statement
    ;

variable_declarator
    : declarator_id
    | declarator_id '=' variable_initializer
    ;

implicit_anonymous_function_signature
    : '(' implicit_anonymous_function_parameter_list? ')'
    | identifier
    ;

implicit_anonymous_function_parameter_list
    : declarator_id
    | implicit_anonymous_function_parameter_list ',' declarator_id
    ;

explicit_anonymous_function_parameter
    : anonymous_function_parameter_modifier? type declarator_id
    ;

Additional contexts include a number of query clauses.

This feature interacts with the out var feature, enabling one to receive a tuple produced in an out parameter into a set of separate names for the tuple elements:

argument_value
    : 'out' type declarator_id
    | ...
    ;

For example a method declared like this

    bool TryGet(Key key, out (int, int) value) { ... }

can be used like this

    if (TryGet(key, out var (x, y))
    {
        // x and y can be used here
    }

This might prove useful, for example, in extracting values from a dictionary whose TValue is a tuple.

Open question: should this syntax be applicable for declaring method parameters?

@MadsTorgersen @VSadov @jcouv

[HaloFour]

Open question: should this syntax be applicable for declaring method parameters?

You mean like this?

bool TryGet(Key key, out (int x, int y)) {
    x = 123;
    y = 456;
    return true;
}

[gafter]

@HaloFour

Almost. With this grammar (type followed by declarator_id), it would be like this

bool TryGet(Key key, out (int, int) (x, y)) {
    x = 123;
    y = 456;
    return true;
}

[AdamSpeight2008]

Shouldn't it be?

bool TryGet(Key key, out (int x, int y) t) {
    t.x = 123;
    t.y = 456;
    return true;
}

as the out parameter is a tuple?

[gafter]

@AdamSpeight2008 No, that is not a use of the feature under discussion here. That is just an ordinary parameter that has a tuple type, and what you wrote will work whether or not this feature request is done. To make it a use of the feature described here, you'd write

bool TryGet(Key key, out (int x, int y) (x, y)) {
    x = 123;
    y = 456;
    return true;
}

[alrz]

I don't think introducing yet another decomposition syntax would be a good idea. As for tuple pattern verbosity we can use an identifier pattern (from Swift) which would also work in positional patterns,

let (x, y) = (1, 2);
let case (var x, var y) = (1, 2);

let Point(x, y) = point;
let case Point(var x, var y) = point;

switch(o) {
  case (var x, var y):
  case let (x, y):

  case Point(var x, var y): 
  case let Point(x, y): 
}

// perhaps only a complete pattern may be used here
// or we can just `continue` when it doesn't match
foreach(let (x, y) in list)

// also, only complete patterns
TryGet(key, out let (x, y));

Should this syntax be applicable for declaring method parameters?

I think the only use case of a tuple deconstruction in out var is when we have a generic type G<T> where T is a tuple. So it would be very unlikely to have an out parameter of a tuple when you are actually declaring a method, and when you do, you don't need individual access to tuple items, IMO.

[HaloFour]

@gafter How about with lambdas?

var list = new List<(int, string)>() {
    (123, "Hello"), (456, "World")
};

list.ForEach(((id, name)) => {
    Console.WriteLine($"{id}: {name}");
});

Might be weird with the parenthesis, especially in the above case where the delegate accepts a single parameter and the parenthesis could normally be omitted, but doing so would make it ambiguous if there was an overload accepting a delegate with two parameters.

[alrz]

@HaloFour I would really like to see this for all complete patterns:

list.Select((let (var id, *)) => id);
// single parameter case
list.Select(let (var id, *) => id);
// or with Scala syntax
list.Select(case (var id, *) => id);

However case expressions seem to be good enough for this use case,

list.Select(t => t case (var id, *): id);

What I don't understand is why there is a need for another decomposition syntax when we have patterns for just this purpose?

[gafter]

@alrz This doesn't have much to do with patterns. We are not considering pattern-matching forms as part of method or lambda parameter specifications. let is a statement. case would be an expression, if we were to choose to do that. Neither of them is a parameter form.

[gafter]

@HaloFour I've updated the syntax to include support for implicit lambda parameters.

[alrz]

My suggestion was based on other languages with pattern matching and tuples like F#, Scala, Swift, etc. They don't have a separate syntax for tuple decomposition, and they do allow patterns in lambda expressions or foreach loops, for example.