[Proposal] Infer generic type arguments from deconstruction variables

[BlinD-HuNTeR]

Consider the following example:

static class Example
{
    static void Deconstruct<T1, T2>(this object[] args, out T1 var1, out T2 var2)
    {
        var1 = (T1)args[0];
        var2 = (T2)args[1];
    }

    static void Test(object[] args)
    {
        (string first, int second) = args; //CS0411: The type arguments for method 'Deconstruct<T1, T2>' cannot be inferred from the usage.
    }
}

Compiler is unable to infer the correct types, even though all necessary information is there.
If I try to manually call the Deconstruct method with out parameters, it works as expected.

It turns out that this is a really simple fix, pretty much one line of code (plus 1 line of XML):

src/Compilers/CSharp/Portable/Binder/Binder_Deconstruct.cs

- 645 var variable = new OutDeconstructVarPendingInference(receiverSyntax, variableSymbol: variableSymbol, isDiscardExpression: variableOpt is BoundDiscardExpression); + 645 var variable = new OutDeconstructVarPendingInference(receiverSyntax, variableSymbol: variableSymbol, isDiscardExpression: variableOpt is BoundDiscardExpression, type: variableSymbol?.GetTypeOrReturnType().Type);

And change the BoundNodes.xml file such that the Type is no longer "AlwaysNull":

src/Compilers/CSharp/Portable/BoundTree/BoundNodes.xml

2529 2529 <Node Name="OutDeconstructVarPendingInference" Base="BoundExpression"> 2530 2530 <!-- Type is not significant for this node type; always null --> - 2531 <Field Name="Type" Type="TypeSymbol?" Override="true" Null="always"/> 2532 2531 <Field Name="VariableSymbol" Type="Symbol?"/> 2533 2532 <Field Name="IsDiscardExpression" Type="bool" Null="NotApplicable"/> 2534 2533 </Node>

After making the above changes, the example compiles perfectly and works as expected.

[BlinD-HuNTeR]

Since no one gave me attention, I decided to implement it myself 😂
I made a NuGet package that hooks into the compiler and enables this exact scenario. Just install the package and the above example magically compiles.

As a bonus, the package also enables inference of type parameters from constraints (based on pull request #7850)

[333fred]

I would highly suggest putting a disclaimer on that package that it is not supported in any fashion, and anyone who uses it is likely to be broken at any time, suffer bad behavior in various IDE scenarios, and is generally using unsafe code.

[BlinD-HuNTeR]

Well, I am not the first person to have the idea of writing an analyzer to inject stuff in Roslyn.

Sure, I could fork the compiler, but no one uses forked versions of roslyn (like OpenSesame), as they don't work inside Visual Studio, and are usually outdated.

I am using IgnoresAccessChecksToAttribute to unlock access to Roslyn internals, with this approach, my package will continue to work with the latest versions of Roslyn, as long as the classes I'm using (mostly MethodTypeInferrer) don't change too much.

Plus, I am not using any form of native-code hooking (like MonoMod.RuntimeDetour, or any other Detour library). All hooking is done through modification of private fields (I take advantage of the fact that static delegates are cached, so I can change them with reflection).

[333fred]

as long as the classes I'm using (mostly MethodTypeInferrer) don't change too much.

So as I said, "not supported in any fashion, and anyone who uses it is likely to be broken at any time, suffer bad behavior in various IDE scenarios, and is generally using unsafe code". You are depending on compiler-internal details that can and will change at any time, and people who use this package are no longer using C#, but a custom dialect based on it.