[Proposal]: Allow var variables to be used in a nameof in their initializers

[333fred]

Allow var variables to be used in a nameof in their initializers

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Today, the following code is invalid:

var a = nameof(a);

Despite this code being valid:

string a = nameof(a);

This proposal makes the first example legal.

Motivation

This is confusing to encounter (not helped by the bad Roslyn diagnostic we give, see dotnet/roslyn#45146, but that's beside the point), and takes some serious spec-lenses to understand why the restriction exists. nameof(identifier) is always a string, and we should make it fine to use a var variable this way.

Detailed design

We modify this section of the specification (edit is to the last bullet, in bold):

In the context of a local variable declaration, the identifier var acts as a contextual keyword (Keywords).When the local_variable_type is specified as var and no type named var is in scope, the declaration is an implicitly typed local variable declaration, whose type is inferred from the type of the associated initializer expression. Implicitly typed local variable declarations are subject to the following restrictions:

In the context of a local variable declaration, the identifier var acts as a contextual keyword (Keywords).When the local_variable_type is specified as var and no type named var is in scope, the declaration is an implicitly typed local variable declaration, whose type is inferred from the type of the associated initializer expression. Implicitly typed local variable declarations are subject to the following restrictions:

• The local_variable_declaration cannot include multiple local_variable_declarators.
• The local_variable_declarator must include a local_variable_initializer.
• The local_variable_initializer must be an expression.
• The initializer expression must have a compile-time type.
• The initializer expression cannot refer to the declared variable itself except as the argument to a nameof_expression.

Drawbacks

All change is scary.

Alternatives

Do nothing.

Unresolved questions

Design meetings

https://github.com/dotnet/csharplang/blob/1754aaafffe270c19d8578af30a2eb768de3ee49/meetings/2021/LDM-2021-02-10.md#allow-var-variables-to-be-used-in-a-nameof-in-their-initializers

[JustNrik]

void Foo(int value, string paramName = nameof(value))
{
}

isn't valid either, can this be covered as well? Thought the error is different but I'm curious to know why it isn't valid

[lechu445]

[return: NotNullIfNotNull(nameof(parameter))]
public static string? Foo(string? parameter)
{
}

and this is not valid

[CyrusNajmabadi]

and this is not valid

This is already tracked by another issue.

[CyrusNajmabadi]

isn't valid either, can this be covered as well?

No. please open a discussion on this :) Thanks!

[KalleOlaviNiemitalo]

The following would then not be allowed, because it refers to s in the argument to a nameof_expression, rather than as the argument. It seems OK not to allow this.

var s = nameof(s.Length);

[333fred]

The following would then not be allowed, because it refers to s in the argument to a nameof_expression, rather than as the argument. It seems OK not to allow this.

var s = nameof(s.Length);

Correct. That would involve knowing the type of s at that point. We just want to allow it when it's the argument to the nameof expression, nothing deeper.

void Foo(int value, string paramName = nameof(value))
{
}

isn't valid either, can this be covered as well? Thought the error is different but I'm curious to know why it isn't valid

Let me dig into why that isn't allowed today. I'd be ok with supporting it.

[333fred]

void Foo(int value, string paramName = nameof(value))
{
}

isn't valid either, can this be covered as well? Thought the error is different but I'm curious to know why it isn't valid

Let me dig into why that isn't allowed today. I'd be ok with supporting it.

So, this comes down the scoping rules laid out here: https://github.com/dotnet/csharplang/blob/master/spec/basic-concepts.md#scopes. Specifically, the lines that read like:

The scope of a parameter declared in a method_declaration (Methods) is the method_body of that method_declaration.

This would be covered by #373, I think.

[MgSam]

All change is scary.

So true.

[Youssef1313]

Should the following be allowed?

I'd say no, but wanted to point out this scenario to consider.

public class C
{
    private string a = "";

    public void M()
    {
        var a = nameof(a);
    }

    private static string nameof(object o) => "NameOfStaticMethod";
}

[333fred]

Should the following be allowed?

I'd say no, but wanted to point out this scenario to consider.

public class C
{
    private string a = "";

    public void M()
    {
        var a = nameof(a);
    }

    private static string nameof(object o) => "NameOfStaticMethod";
}

Nope. A method call is not a nameof_expression. It is a good test case though.

[HurricanKai]

in regards to this sample:

var s = nameof(s.Length);

Correct. That would involve knowing the type of s at that point.

the type can be inferred though. nameof always returns a string, therefore even a "recursive" definition like that could be valid.
I don't see much use though, I mean that's just the same as nameof(string.Length)

[333fred]

in regards to this sample:

var s = nameof(s.Length);

Correct. That would involve knowing the type of s at that point.

the type can be inferred though. nameof always returns a string, therefore even a "recursive" definition like that could be valid.
I don't see much use though, I mean that's just the same as nameof(string.Length)

This particular use case is degenerate. But it could be more like var s = Method(nameof(s.Length));, where Method is defined as T Method<T>(T arg) => arg;.

[Rekkonnect]

Another thing is that the following code is also valid:

dynamic s = nameof(s);