Improve Deconstruct resolution to handle two or more methods with the same number of parameters

[DavidArno]

The following code:

namespace Deconstructions
{
    class Program
    {
        static void Main()
        {
            var foo = new Foo();
            (string x, string y) = foo;
        }
    }

    public class Foo
    {
        public void Deconstruct(out string x, out string y) => (x, y) = ("", "");
        public void Deconstruct(out string x, out int y) => (x, y) = ("", 0);
    }
}

results in the compiler complaining that:

Error	CS0121	The call is ambiguous between the following methods or properties: 
'Foo.Deconstruct(out string, out string)' and 'Foo.Deconstruct(out string, out int)'

out parameters were chosen for Deconstruct's to support multiple overloads. It seems odd therefore that the deconstruct behaviour should not be able to resolve which one to use, based on matching the types of those out parameters to the types of the deconstruct expression.

There seems room for improving deconstruct behaviour in future for situations where two Deconstruct methods exist with clearly different parameter types.

[HaloFour]

@DavidArno

out parameters were chosen to support overloads of different arity. Trying to have multiple deconstructions of the same arity differing only on type seems like it would be really confusing, like trying to influence overload resolution based on the potential assignment of the return type of a function. I'd argue that even if it is possible that it shouldn't be encouraged.

[alrz]

In order to make this work, we need to list the types that a particular pattern can be matched against - basically a backward overload resolution.

Note that this is possible:

public class Foo
{
  void Deconstruct(out byte x, out byte y) => throw null;
  static void Main() {
    (int x, int y) = new Foo();
  }
}

Now imagine you have overloaded Deconstruct methods.

[DavidArno]

@alrz,

The compiler handles resolving which methods to use with different arities but differently typed out parameters just fine for non-deconstruct scenarios:

private void Foo(out byte x) => x = 0;
private void Foo(out int x) => x = 1;

Foo(out int x); // x == 1

Why would it be any harder for deconstructs?

[alrz]

@DavidArno

Look at my example more closely. I'm deconstructing a byte to int which is not possible with explicitly typed out args. So the compiler needs to figure out the exact type for out arguments which might not be identical to the deconstructed types.

[DavidArno]

@alrz,

Ha, just spotted that and was half way through editing my reply when you pointed it out 😀

So the steps the compiler takes are:

1. Is there exactly one overload that exactly matches the types in the deconstruct? If yes, use that.
2. If not, is there exactly one overload that matches when implicit casting (and base types) is used? If yes, use that.
3. If no, to the above two, due to there being more than one matching overload that matches, report that as an error.
4. If none of the above, report no match, even using implicit casting, exists.

Not so hard, really.

(Not sure about base types being in 2; they may need to be part of 1).

[alrz]

is there exactly one overload that matches when implicit casting (and base types) is used?

With recursive patterns, you'll be able to execute Deconstruct as a consequence of using a positional pattern. Since a pattern doesn't have a type you can't just rely on implicit conversions -- per spec, patterns maintain a set of types as "pattern compatible types" i.e. types that a pattern can be used to be matched against. Currently there is no mechanism to infer string from an untyped pattern like {Length: 2} but we can say that string is pattern compatible with {Length: 2} (reversed).

[DavidArno]

True, but won't those recursive patterns reply on bool Deconstruct(... methods? That feels like an orthogonal issue to me. But I may have it wrong...

[alrz]

It doesn't have anything to do with bool-returning Deconstruct methods, consider this:

public class Foo
{
  void Deconstruct(out Bar x, out byte y) => throw null;
  void Deconstruct(out Baz x, out int y) => throw null;

  static void Main() {
    if (new Foo() is ({Length: 2}, var x))
  }
}

Your (2) rule can't be applied to {Length: 2} because there is no type to check implicit conversions. We will need to lookup Length property on both Bar and Baz types to figure out which (if any) is pattern compatible. (and the type of x may change based on the winner candidate).

[MkazemAkhgary]

if there are overloads how this works then?

var (x, y) = foo;

[DavidArno]

@alrz,
Ah, I see what you mean. So "Not so hard, really" only works if I ignore the hard stuff! 😁

Oh well, it was a fun idea whilst it lasted.

[DavidArno]

@MkazemAkhgary,

Short answer: it doesn't. If you have two arity 2 Deconstruct methods at the moment, that won't work. As there's no type information, it would continue not to work under this proposal.

[MkazemAkhgary]

this is a good proposal by the way, I'm wondering though why its not allowed in case types are well defined. like (string x, string y) = foo;

It sounds reasonable for var it would be ambiguous, just like when you call method overload with out var x passed as argument.

[gafter]

@DavidArno Please close this if you've abandoned it. If you still like it, please explain how it should interact with pattern-matching.