Work out how "nameof" interacts with "this"

[jskeet]

Originally reported on #926.

Some comments from @KalleOlaviNiemitalo

A surprising interaction with nameof:

struct S {
    int i;
    
    void M() {
        string N() {
            return nameof(this);  // error CS1673
        }

        string O() {
            return nameof(this.i);  // error CS1673
        }

        string P() {
            return nameof(i);  // OK, returns "i"
        }
    }
}

To be checked:

• nameof(this) in a default parameter or in an attribute argument (thus not in the function body) in a local or anonymous function in a struct

using System;
class DAttribute : Attribute {
    public DAttribute(string s) {}
}
struct S {
    int j;
    void LeA() {
        // OK
        Action<int> a = ([D(nameof(this.j))] int i) => {};
    }
    void LeD() {
        // error CS1065, default value not allowed
        Action<string> action = (string s = nameof(this.j)) => {};
    }
    void LfA() {
        // OK
        void F([D(nameof(this.j))] int i) {}
    }
    void LfD() {
        // error CS1673, cannot access this in local function
        void F(string s = nameof(this.j)) {}
    }
}

That seems pretty inconsistent. Why is nameof(this.j) allowed in an attribute argument in the parameter list, but not in a default parameter value? Is that what the standard should specify?

Expression trees seem to allow neither attributes nor default values, so the behaviour is more consistent for them:

using System;
using System.Linq.Expressions;
class DAttribute : Attribute {
    public DAttribute(string s) {}
}
struct S {
    int j;
    void ExA() {
        // error CS8972, attribute not allowed in expression tree
        Expression<Func<string, string>> e = ([D(nameof(this.j))] string s) => "";
    }
    void ExD() {
        // error CS1065, default value not allowed in expression tree
        Expression<Func<string, string>> e = (string s = nameof(this.j)) => "";
    }
    void ExR() {
        // error CS1673, lambda expression in struct cannot access this
        Expression<Func<string, string>> e = (string s) => nameof(this.j);
    }
}

[BillWagner]

@jskeet As you work on nameof behavior, be aware that here be (generally harmless) dragons. The behavior of nameof is one of the places where the newer compiler doesn't perfectly match older implementations wheh the LangVersion is set to an older value.

See here: dotnet/docs#36980 (comment)

[jskeet]

@BillWagner: Good to know, thanks. Not expecting to work on nameof for a while though :)

[jnm2]

nameof(this) should always give "CS8081 Expression does not have a name." Once that's out of the way, we just have this interesting case:

struct S
{
    void M()
    {
        string L(string s = nameof(this.M)) // error CS1673
        {
            return nameof(this.M); // error CS1673
        }
    }
}

I'm very sure that error CS1673 should not be reported here. The message is:

Anonymous methods, lambda expressions, query expressions, and local functions inside structs cannot access instance members of 'this'. Consider copying 'this' to a local variable outside the anonymous method, lambda expression, query expression, or local function and using the local instead.

Thus, the error is only about accessing instance state, and nameof does not access state, so it does not apply to nameof.

Interestingly in C# 9, when attributes become allowed on local function parameters, nameof(this.M) does work as a local function attribute argument even though it is not allowed as a default value for an optional parameter in the same signature:

struct S
{
    void M()
    {
        void L([DefaultValue(nameof(this.M))] string? s) // No error!
        {
        }
    }
}

So, the error is not consistently given, and when it is given, the error message makes no sense (it says we're attempting to access state, which we're not). This seems like a compiler bug to me. I could imagine it being fixed retroactively given the lack of coherence, and the fact that it would not break anyone to fix it. Thus, maybe we can just imagine that it's already fixed when deciding what to specify?

[jnm2]

Bug report: dotnet/roslyn#78983