C#8: Switch expression return tuple - tuples

Question

why this
(Func<Window> win1, int i1) = ( () => new Window(), 1);
and this
(int i2, int i3) = 1 switch {
1 => (2, 1),
_ => throw new ArgumentOutOfRangeException()
};
works.
but that doesn't
(Func<Window> win2, int i4) = 1 switch {
1 => (() => new Window(), 1),
_ => throw new ArgumentOutOfRangeException()
};

Answer 1

The reason behind these inconsistencies is because your different examples hit different aspects of deconstructors and type inference.
Your first case is an example of a side effect of an optimisation added to C# 7.1 which optimises away a deconstruct of a tuple. This was introduced to allow the use of a constructor pattern:
public class Person
{
public string Name { get; }
public int Age { get; }
public Person(string name, int age) => (Name, Age) = (name, age);
}
without incurring the overhead of assigning a tuple and then deconstructing it. The compiler "lowers" that contructor to:
public Person(string name, int age)
{
Name = name;
Age = age;
}
Therefore, when the compiler encounters:
(Func<Window> win1, int i1) = ( () => new Window(), 1);
it converts it to:
Func<Window> win1 = new Window();
int i1 1;
All types are known and so all is well.
Your next example can be better explained if we change it to:
var a = 1 switch {
1 => (2, 1),
_ => throw new ArgumentOutOfRangeException()
};
This expression takes advantage of the fact that the compiler ignores the throw when determining the type of a switch expression. There's only one other arm, which it can infer is of type (int, int). It chooses that as the return type for the switch expression and a is inferred to be of type (int, int).
With your example, you are then taking that tuple and deconstructing it into two int's: i1 and i2. Because the type of the expression is known, the compiler is happy that it knows how to deconstruct that expression.
Before addressing your last example, we again need to modify it slightly:
(Func<Window>, int) tmp = 1 switch {
1 => (() => new Window(), 1),
_ => throw new ArgumentOutOfRangeException()
};
This code compiles. The reason is because we are now using a target-typed switch expression. If the compiler cannot infer the type of the switch expression from the arms of that expression, then it looks to the target of the expression (in this case an assignment) to see if that has a type that satisfies all the arms of the switch expression. C# doesn't infer a delegate type for lambdas; it requires they be explicity typed or inferred. In this example, the type (Func<Window>, int) is a suitable type for all the arms of the switch expression, so that type is used.
This approach doesn't work for your example though as you have a deconstruct on the lhs of the assignment. The deconstruct needs to know the type it's deconstructing and the switch expression needs a target type. As you point out in a comment, there's a quirk of the compiler that satisfies both of these: delare a variable after the deconstruct:
(Func<Window> win2, int i4) tmp = 1 switch {
1 => (() => new Window(), 1),
_ => throw new ArgumentOutOfRangeException()
};
The compiler then lowers that to:
(Func<Window>, int) tmp = 1 switch {
1 => (() => new Window(), 1),
_ => throw new ArgumentOutOfRangeException()
};
(Func<Window> win2, int i4) = tmp;
The compiler certainly could avoid this and infer that variable itself, but that would need to be proposed and adopted as an enhancement to the language. Head on over to dotnet/csharplang discussions on github if you fancy doing that.
Update: I've created a discussion there: Should C# support mixing deconstructors and target-typed switch/option expressions as it seems an important point to discuss anyway.