[Proposal]: Allow nameof(method parameter) outside the method.

[Youssef1313]

Allow nameof(method_parameter_name)

• [x] Proposed
• [ ] Prototype: Not Started
• [ ] Implementation: Not Started
• [ ] Specification: Not Started

Summary

Currently, there is no way to use a parameter name outside the method without hardcoding it.

Motivation

Extending nameof capabilities and allowing it to be used in more contexts. Similar to: https://github.com/dotnet/csharplang/issues/4384, and extends https://github.com/dotnet/csharplang/issues/373 (not a dupe of it)

Detailed design

While #373 suggests allowing nameof for parameter names in attributes applied to the method, this proposal is a suggestion to generalize it to be allowed outside the method context. A real-world example that can benefit from this:

https://github.com/dotnet/roslyn-analyzers/blob/b76ff2f/src/Microsoft.CodeAnalysis.Analyzers/Core/MetaAnalyzers/DiagnosticDescriptorCreationAnalyzer.cs#L29-L35

public class C
{
    public void M()
    {
        var x = nameof(M.s); // Same as var x = "s";
        var x = nameof(M.y); // Compile error.
    }

    public void M(object s) { }
}

Drawbacks

• A simple member access expression for parameter name could be confusing (consider another operator?)
• How IDE should work in case of renaming?

Alternatives

Unresolved questions

Design meetings

• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-03-09.md#nameofparam

[YairHalberstadt]

Would you be able to access members of the parameter as well? E.g. in your example nameof(M.s.ToString)?

[Youssef1313]

Would you be able to access members of the parameter as well? E.g. in your example nameof(M.s.ToString)?

Probably depends on the ease of implementation. There is already a cleaner way to do that (nameof(WhateverTypeTheArgumentIs.ToString)).

[HaloFour]

The syntax of using member access to reference a parameter of a method feels really weird here, as does the name resolution (although you could argue that the latter is already "broken" by method group resolution). It gets much weirder if you can dot into the members of the parameter type, especially if there are overloads of that method that could have parameters of the same name but of different types.

What are the use cases where you'd want to take the name of a method parameter in a separate method body?

[Youssef1313]

The syntax of using member access to reference a parameter of a method feels really weird here, as does the name resolution (although you could argue that the latter is already "broken" by method group resolution). It gets much weirder if you can dot into the members of the parameter type, especially if there are overloads of that method that could have parameters of the same name but of different types.

What are the use cases where you'd want to take the name of a method parameter in a separate method body?

The use case that come to mind is mostly for analyzers, such as the example provided.

---

It gets much weirder if you can dot into the members of the parameter type, especially if there are overloads of that method that could have parameters of the same name but of different types.

That's correct. In that case I think accessing into the members of the parameter should be completely disallowed.

---

The syntax of using member access to reference a parameter of a method feels really weird here

Could we consider another token other than the DotToken?

[ashmind]

What are the use cases where you'd want to take the name of a method parameter in a separate method body?

One use case is to register specific parameter value during dependency injection registration. It's a bit of an edge case, but I still run into it periodically. Something like this (artificial):

builder.RegisterType<Processor>()
       .As<IProcessor>()
       .WithParameter("timeout", config.Timeout);

Note that it requires nameof access to constructor parameters though.

[TahirAhmadov]

Will this support parameters of methods in other types?

const string s = nameof(My.Namespace.Class.Method.parameter);

[333fred]

Currently, there is no proposal for adding such semantics.

[Jawvig]

Another example of usage would be attributes. For instance, in the Open API & Azure Functions attributes OpenApiParameterAttribute and HttpTriggerAttribute respectively. For example:

/*...*/
[OpenApiParameter(name: nameof(FuncClass.SomeFunction.someParam), In = ParameterLocation.Path /*, ... */)]
/*...*/
public async Task<IAsyncResult> SomeFunction(
    [HttpTrigger(/*...*/ Route=$"abc/{{{nameof(FuncClass.SomeFunction.someParam}}}/abc")] HttpRequest request,
    string  someParam)
{
   /* ... */
}

Even better would be if some of the context could be inferred so that the class or method name don't need to be applied based on the target of the attribute.

[Jawvig]

Never mind, I should have read the proposal in more detail as the use in attributes is in https://github.com/dotnet/csharplang/issues/373