Proposal: a MatchParameterNames attribute for delegates

[ymassad]

I am proposing to limit the methods that a custom delegate can point to if the delegate has a custom attribute, e.g. called MatchParameterNames.

Example:

[MatchParameterNames]
public delegate void Delegate1(int a);

public class C1
{
    public void Test()
    {
        Delegate1 d1 = M1; //Valid
        Delegate1 d2 = M2; //Compilation error
    }

    public  void M1(int a){}
    public void M2(int b){}
}

If there is a method group with two overloads like this:

public void M3(Delegate1 d)

public void M3(Action<int> d)

And you call M3(b =>{}), then the first overload of M3 will not be considered because the lambda is actually a method with a parameter called b and thus cannot be assigned to Delegate1. In this case, the second overload will be used.

This feature can be used if a library author wants to force users of the library to use certain names of lambda parameters.

[HaloFour]

Can you provide any use cases where this would actually be useful? Given the massive amount of functional code within LINQ and similar projects there seems to be little issue with managing overloads that accept delegates intended to accept lambdas.

IMO, parameter names are not a part of the signature of a method or a delegate. Developers should be able to name them freely based on their needs, and changing those names should not change the behavior of the source.

[theunrepentantgeek]

If implemented, renaming parameter names would become an API breaking change - currently we're free to rename parameter names without breaking consumers.

This seems like a situation where a custom analyzer would be a perfect fit, allowing you to easily opt-in to these checks without imposing the constraint on the entire C# ecosystem.

[CyrusNajmabadi]

currently we're free to rename parameter names without breaking consumers.

Renaming parameters is currently a breaking change.

[ymassad]

The real use case why I need this is for code generation.

Based on the names of the lambda parameters, I can generate a new extension method with a new delegate type.

If someone writes

Method1((int a, int b) => a + b);

I can generate an overload of Method1 that returns the following new type:

public class Type1
{
    public int a;
    public int b;
}

I will do that by generating a new delegate:

[MatchParameterNames]
public delegate int Delegate1(int a, int b);

And generating an overload that takes Delegate1 and returns the generated type Type1.

If the user uses different lambda parameter names, a new overload will be generated and the two invocations of Method1 can exist safely.

This is not the exact use case. But it captures the idea.

In summary, this will enable source generation scenarios where lambda parameter names participate in the result of the generation.

[ymassad]

If implemented, renaming parameter names would become an API breaking change - currently we're free to rename parameter names without breaking consumers.

This is an issue only for delegates with the [MatchParameterNames] attribute. Not for all delegates. Tooling can be updated to deal with these kinds of scenarios where the user is warned when dealing with these types of delegates.

This seems like a situation where a custom analyzer would be a perfect fit, allowing you to easily opt-in to these checks without imposing the constraint on the entire C# ecosystem.

Currently, analyzers enable me to prevent the user from specifying the wrong names, but it doesn't force c# to use a different method overload.

A compiler seam (like analyzers and source generators) where we can participate in overload resolution (e.g. to reject some overloads that the compiler selects and force it to look for the next best thing) will work.

[333fred]

A compiler seam (like analyzers and source generators) where we can participate in overload resolution (e.g. to reject some overloads that the compiler selects and force it to look for the next best thing) will work.

Well, I can say that definitely won't happen. C# users expect overload resolution to behave consistently, allowing 3rd parties to interact with the algorithm is the opposite of consistent.

This seems to me like a good use case for analyzers. Just issue an error when parameter names don't line up.