Infer types from generic constraints

[HellBrick]

This is a prototype of #5023. See #5023 (comment) for the description of the implementation mechanics.

[dnfclas]

Hi @HellBrick, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.dotnetfoundation.org.

TTYL, DNFBOT;

[dnfclas]

@HellBrick, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.

Thanks, DNFBOT;

[bbarry]

It looks like these tests are failing exactly for the reason the code was changed. The expected refactorings no longer need the type parameters on these method calls with the change here:

in EditorFeatures/CSharpTest/ExtractMethod/ExtractMethodTests.cs

• line 8148
• line 8840
• line 8885
• line 8933
• line 9004

Edit: also the comments in the MethodTypeInference.cs file should be updated to match spec changes.

[HellBrick]

Thanks, I've fixed the tests.

[HellBrick]

Edit: also the comments in the MethodTypeInference.cs file should be updated to match spec changes.

That's a bit tricky, since there is no updated spec at this point =)

[SolalPirelli]

I see that your tests use methods with one argument; would this also work with parameterless methods, e.g. M<T, X>() where T : IEnumerable<X> called as M<List<int>>()? (sorry, my computer is in a bit of a messy state right now, can't check for myself)

[bbarry]

No. This change is about getting rid of some (all?) cases where the generic parameters are already fixed (you might be able to tighten them further) but the compiler fails to tell so the developer must supply them.

[khellang]

Will this solve this problem (inferred return type) as well?

EDIT: Seems like it does. Pulled down the code and took it for a test drive. Nice work.

[davkean]

tag @dotnet/roslyn-compiler

[HellBrick]

@SolalPirelli It doesn't work like that. This PR improves the type inferrer, but in your case it's never actually invoked. Waaaaaay earlier down the stack the compiler detects that method is called with less type arguments than required and produces an error. If this behavior is altered to try inferring the missing types before failing, then the mechanism from the current PR would kick in and save the day. But I believe it's a separate issue (#6207 looks related).

[gafter]

@HellBrick We'll take a look at this, thanks!

[davkean]

test eta please

tag @dotnet/roslyn-compiler

[gafter]

@HellBrick Nice work! We're still discussing it (but mostly we have vacations that prevent us from meeting much until January).

[davkean]

@gafter @dotnet/roslyn-compiler It's been nearly ~3 weeks, can we take a look?

[HellBrick]

mostly we have vacations that prevent us from meeting much until January

It's January now =) Any plans for further action here?

[gafter]

Our plans are to meet around the third week of January and start prioritizing our language design work.

[gafter]

@HellBrick OK, the LDM looked at this very briefly, and we decided that we don't want to make language changes to overload resolution in 1.2 (except to fix compat bugs). We can consider it for a later language version (i.e. version 2.0, tentatively called C# 7). And I am still interested in pushing it through the process.

Can you please retarget this to the future branch (i.e. close this PR and open a new PR against the future branch]?

Tag me on the new PR and I'll continue working it with the language team.

/cc @MadsTorgersen

[HellBrick]

Sure, I'll open a new PR tomorrow. It's a pity though that such a small nice improvement has to wait until the next major language version. If you don't mind me asking, what's the reason behind postponing it? I'm just trying to get a better understanding of your process and to see if there's anything else that can be done here to simplify acceptance of this feature.

P.S. Out of curiosity: what are the minor milestones (1.2, 1.3) mapped to, timeline- or release-wise? Do they correspond to the upcoming VS 2015 updates?