Proposal: Disambiguating methods with nameof operator

[HaloFour]

Currently the nameof lacks the ability to disambiguate overloads which makes it fragile when used to capture a method name. When using refactoring tools in Visual Studio it's impossible to determine which overload nameof would apply to so the IDE leaves the nameof operator alone as long as there are any other methods with that same name.

I propose supporting additional syntax with nameof to allow it to disambiguate which overloaded method to which it applies. This would fix the refactoring fragility above as well as open the doors to other operators which would require such disambiguation, e.g. methodof or infoof.

The proposal is that for a method group you can optionally add a parenthesis-enclosed comma-separated list of types following the identifier. This list of types would be used to disambiguate potential overloads of that method group by exact binding.

public class Foo {
    public void M(int i) { }
    public void M(string s) { }
    public void M<T>(T t) { }
    public void M<T>(T t, string s) { }
}

// today
nameof(Foo.M); // matches non-generic method group
nameof(Foo.M<int>); // matches generic method group

// proposed
nameof(Foo.M(int)); // matches Foo.M(int i) specifically
nameof(Foo.M(string)); // matches Foo.M(string s) specifically
nameof(Foo.M<int>(int)); // matches Foo.M<T>(T t) specifically
nameof(Foo.M<int>(int, string)); // matches Foo.M<T>(T t, string s) specifically

nameof(Foo.M(short)); // error

[qrli]

This is very valid from refactor point of view.
But I don't think it is common to rename a single overload. So it may be much cheaper to solve at refactor tool side.

[jnm2]

But I don't think it is common to rename a single overload.

I'd say for me it's split 60/40 whether I'm renaming the whole group or a single method. It really has to do with the refactor I'm doing and what the callers are.