Please provide nameof() for generic type paremeter's properties

[gafter]

@m08pvv commented on Tue Apr 12 2016

Version Used: shipped with VS 2015 Update 2

For this code:

class GenericsTest
{
    interface ISomeInterface
    {
        string SomeValue { get; set; }
    }

    class SomeInterfaceImpl : ISomeInterface
    {
        public string SomeValue { get; set; }
    }

    private void Method<T>()
        where T : ISomeInterface
    {
        var ok = nameof(SomeInterfaceImpl.SomeValue);
        var error = nameof(T.SomeValue);
    }
}

Expected Behavior:
both nameof() should be allowed

Actual Behavior:
nameof() for type parameter is not allowed

---

@jamesbascle commented on Wed Jul 13 2016

Could do nameof(ISomeInterface.SomeValue). What is the advantage of using T? It seems counter to the way all the other nameof stuff works, where you reference the compile time types, rather than parameters or type parameters.

[jnm2]

What's the downside of directly using the name of the type that declares the member, rather than using the generic type parameter?

[m08pvv-zz]

@jnm2 No downsides, it was just spontaneous desire from colleague during some pair programming session.

[jnm2]

Just curious if I was missing something. It's in line with other things you can already do like nameof(randomVariable.Member) so I'm not opposed.

[MgSam]

If it provides literally zero benefit, then its not worth the time spent changing it and testing that change.

[m08pvv-zz]

@MgSam Yes, you can close this ticket.

[jnm2]

@gafter thought it was worth discussing on csharplang, let's maybe hear what the C# team's perspective would be.

[iam3yal]

To me it sounds like this should be supported just for completeness, it reduces duplication of what the compiler already knows on the expense of readability, I find the former where you explicitly spell out the interface more readable.

[jnm2]

I have a string of use cases for nameof(InstanceInScope.Member) because in these cases, when you consider refactoring, what's truly important is the fact that the member is available on InstanceInScope and not the fact that it's available on a given type. This is common in data binding and testing scenarios.

I was curious if someone had a similar scenario with type parameters, but either way completeness is not a bad thing.

[MgSam]

Every feature comes with not just the cost of implementing it but the opportunity cost of working on something else, potentially more valuable.

Do you believe that this feature is more valuable than something else they could instead be working on?

[jnm2]

Do you believe that this feature is more valuable than something else they could instead be working on?

There are always two phases: judging whether a feature is good or bad, and judging the feature's priority. It's good to not mix them up.