Proposal: allow open types in nameof

[jskeet]

(Created from #4827)

Currently to use nameof with a generic type, a type argument needs to be used. Problems:

• It's very odd to require something to be specified within an operand when it has no impact on the result
• It's inconsistent with typeof
• It means that changing a constraint on a type parameter can break uses of nameof entirely unnecessarily

I propose that the exact same syntax as typeof is used. So for example:

class GenericClass<T>
{
    public string X { get; }
}

class GenericClass<T1, T2>
{
    public string Y { get; }
}

These expressions are currently valid, and would stay valid:

nameof(GenericClass<int>)
nameof(GenericClass<int>.X)
nameof(GenericClass<int, byte>)
nameof(GenericClass<int, byte>.Y)

These expressions would become valid, and would have the same respective results:

nameof(GenericClass<>)
nameof(GenericClass<>.X)
nameof(GenericClass<,>)
nameof(GenericClass<,>.Y)

Using the terminology in https://github.com/ljw1004/csharpspec, it may be that all we need to do in grammar terms is to expand named_entity_target to include unbound_type_name, but I suspect it's more subtle than that.

[alrz]

Should nameof(GenericClass<>) return "GenericClass`1"?

[jnm2]

Should nameof(GenericClass<>) return GenericClass`1?

Absolutely not. The main use case for nameof(GenericClass<>) is to follow changes to the name GenericClass around even if you rename-refactor GenericClass<> without renaming GenericClass or GenericClass<,>.

I'm not normally one to throw a ton of emoji reactions at things, but I'm still in disbelief that C# hasn't shipped with this yet. Also, I'd like an analyzer to warn on nameof with closed types and a quick fix.

[alrz]

A GenericClass<,> is different from a GenericClass<>; if you change arity, the latter would not be the same type. In fact, System.Type.Name for open generic types follows the above pattern and returns different names.

[iam3yal]

@alrz It should return a similar thing to typeof(...) so typeof(IList<>).ToString() would return System.Collections.Generic.IList`1[T] so I guess that nameof((IList<>) should return IList`1[T].

[jnm2]

@alrz I don't disagree, but the important part, what nameof was created for, is not the CLR mangled type name but rather the C# language name.

This is borne out. Try nameof(List<int>). You get List.

The only reason to specify <> vs <,> is to disambiguate which of the two classes you're following the name of, should just one of the two classes be renamed:

class GenericClass<T> { }
class GenericClass<T, TOther> { }

nameof(GenericClass<>): GenericClass
nameof(GenericClass<,>): GenericClass

class GenericClass<T> { }
class GenericClassNewName<T, TOther> { }

// Rename refactor was able to track that we care about the name of the unary class in this scenario
nameof(GenericClass<>): GenericClass
// Rename refactor was able to track that we care about the name of the binary class in this scenario
nameof(GenericClassNewName<,>): GenericClassNewName 

[iam3yal]

@jnm2 Yeah you got a point. 😄

[alrz]

not the CLR mangled type name but rather the C# language name

That could be the case. Not sure about nameof, but dotnet/roslyn#10972 certainly works for me.

[jnm2]

@alrz If you wanted the CLR type name, typeof(GenericClass<>).Name has always been a handy tool for that.

[iam3yal]

@jnm2 Yes, only it's not a constant.

[jnm2]

That's right, but it could be if Roslyn starts recognizing typeof(x).Name as constant. Even so it would not have the same uses cases as nameof.

[jskeet]

As per the original proposal, I'm suggesting that using the open type should produce the same results as a constructed type. While I can see there being uses for the generic form, we can't change the results of nameof with the constructed type now, and it would be highly inconsistent for the open type to give a different result.

[paulomorgado]

However, I'm pretty comfortable with using constructed types, as I'm already used to it.

[alrz]

I think using discards would make the implementation easier as there would be no syntax changes.

nameof(GenericClass<_>)
nameof(GenericClass<_>.X)
nameof(GenericClass<_,_>)
nameof(GenericClass<_,_>.Y)

[iam3yal]

@alrz Shouldn't this typeof(IDictionary<_>) work too?

[alrz]

@eyalsk It could, but it does not resolve any ambiguity because there is none. typeof is a keyword so the compiler wouldn't have any problem to permit a special "open generic" syntax in that context, but nameof on the other hand, is a contextual keyword as it parsed as an invocation expression. Not that it wouldn't be possible but I think that it requires syntax changes. It could take advantage of _ being an identifier, just like it has been done for type patterns.

EDIT: The parser does seem to be totally capable of producing syntax nodes for missing identifiers.

[gafter]

@jnm2 Sorry, @jskeet didn't outline a language grammar. If you don't have any idea either, I'll let the issue sit.

[gafter]

To be clear, the problem is that nameof is treated as an invocation expression for purposes of syntax analysis. And an invocation expression simply cannot have an open type in it.

[jnm2]

@gafter I am not familiar with language grammar, but it seems obvious to me that nameof will have to be treated as an entirely new hybrid class of expression.

[gafter]

@jnm2 I agree, that would work. But we treat it as an invocation expression so we do not break backward compatibility.

[jnm2]

tl;dr Go here

I want this badly enough that I'll get up to speed on language grammar to help get this through, but I doubt I'm the most valuable person in this thread for that purpose. :')

What if the hybrid expression, the argument to nameof, could be an InfoOf expression in reference to the infamous infoof operator we've talked about for years? For now it could only be used as an argument to nameof but this opens doors for the future.

List<>.Count would be the spiritual equivalent of typeof(List<>).GetProperty("Count"), and List<int>.Count would be the spiritual equivalent of typeof(List<int>).GetProperty("Count"). It wouldn't make a difference to nameof which one you write, because it's getting the C# language name of Count which doesn't change depending on the type parameter. (In the spirit of MemberInfo.Name but the language name, not the CLR name, if they should ever differ.)
ReSharper sorry, an analyzer would suggest that you simplify the expression by removing closed generic types for nameof. However, if in the future we add infoof, there would be a real difference between the open and closed InfoOf expressions. Similar to the difference MakeGenericType and MakeGenericMethod make.

But we treat it as an invocation expression so we do not break backward compatibility.

At a source level, any currently-valid argument to nameof would remain valid as an InfoOf expression. Can you help me understand the compatibility issue in more detail? Is it just a Roslyn API back-compat issue?

[jnm2]

tl;dr Go here

https://github.com/dotnet/csharplang/blob/master/spec/expressions.md#nameof-expressions

Okay, so the operand to nameof, what is currently called the named_entity expression, would be what I was calling the InfoOf expression.
And if you took to the info_of expression idea, this sentence would be removed:

It is a compile-time error for a named_entity designating a method group to have a type_argument_list.

But that would be a problem for info_of expressions because of back-compat. Perhaps it's better they stay separate from named_entity.

(See, I doubt I'm the most valuable person in this thread...)

[jnm2]

To get back to basics here, this is what we currently have (spec#nameof-expressions):

named_entity
    : simple_name
    | named_entity_target '.' identifier type_argument_list?
    ;

What if there was a version of named_entity but with generic_dimension_specifier instead of type_argument_list?

[jnm2]

@gafter How is this?

nameof_expression
    : 'nameof' '(' named_entity_open ')'
    : 'nameof' '(' named_entity_closed ')' // For back-compat
    ;

named_entity_open
    : simple_name
    | named_entity_target_open '.' identifier generic_dimension_specifier?
    ;

named_entity_target_open
    : 'this'
    | 'base'
    | named_entity_open // Gotta be open all the way: TypeA<int>.TypeB<> doesn't make sense
    | predefined_type 
    | qualified_alias_member
    ;

named_entity_closed // For back-compat
    : simple_name
    | named_entity_target_closed '.' identifier type_argument_list?
    ;

named_entity_target_closed // For back-compat
    : 'this'
    | 'base'
    | named_entity_closed // Gotta be closed all the way: TypeA<>.TypeB<int> doesn't make sense
    | predefined_type 
    | qualified_alias_member
    ;

[CyrusNajmabadi]

A simple way to handle this from the grammar would be to just change:

simple-name:
    identifier   type-argument-list

into

simple-name:
    identifier   type-argument-list
    identifier   generic-dimension-specifier

With normative text to specify that the latter are only legal in the respective locations in typeof/nameof.

--

This grammar would be essentially mimic what we are already doing in the C# parser today. i.e we support "generic-dimension-specifiers" everywhere, we just report errors if you use them in inappropriate locations.

We do this to make parsing simple and to reduce the number of node types we need. i.e. we don't need multiple type of type-argument-lists. But we then go and enforce that you're not using the wrong type of node in the wrong location.

[gafter]

The spec grammar is ambiguous, because it requires semantic context to distinguish a typeof operator from a method invocation of the same name. The compiler simply parses an invocation expression. So it is the method invocation grammar that needs to be adjusted.

[jnm2]

@CyrusNajmabadi @gafter Do you need any more guesswork from me or do you have a handle on it? :)

[craigajohnson]

Absolutely yes please to this feature and please include VB.

[jnm2]

@jskeet Would you please port this to csharplang?

[jskeet]

@jnm2: Done - follow the link above :)

[jnm2]

Championed proposal being scheduled for LDM soon: #8480