[Proposal]: Unbound generic types in nameof

[jnm2]

• Proposal added
• Prototype:
  - Support Open-Generic-Types in 'nameof' expressions. roslyn#4902 and Support Open-Generic-Types in 'nameof' expressions. roslyn#4907 by @CyrusNajmabadi
  - Allow open types in nameof roslyn#20450 by @alrz
• Implementation: Support unbound generic types in 'nameof' operator. roslyn#75368
• Discussed in LDM
• Decision in LDM (Approved)
• Specification: https://github.com/dotnet/csharplang/blob/main/proposals/unbound-generic-types-in-nameof.md

Summary

Allows unbound generic types to be used with nameof, as in nameof(List<>) to obtain the string "List", rather than having to specify an unused generic type argument in order to obtain the same string.

See https://github.com/dotnet/csharplang/blob/main/proposals/unbound-generic-types-in-nameof.md for detailed spec.

Design meetings

https://github.com/dotnet/csharplang/blob/main/meetings/2017/LDM-2017-11-06.md#roslyn-20450
https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-10-16.md#unbound-generic-types-in-nameof

[koszeggy]

Finally! As of today I use a dummy internal type named _ so I can have expressions like

nameof(A<_>)
nameof(Dictionary<_,_>.Count)

[jnm2]

@koszeggy How do you use discards then, e.g. expr switch { Something => 1, _ => 2 }?

[koszeggy]

@jnm2: interestingly enough, it doesn't cause any conflicts. I can simply use the regular discard even when switching on types (like here), and it's not interpreted as my dummy _ type, so I can just use it freely as illustrated above.

[MgSam]

From LDM notes:

We have sympathy. It feels like a corner that's cut. But it's quite expensive to implement, and has semantic dark corners (List<>.First.Foo).

Is this still the case and the LDT is now willing to take on the cost?

Would implementing this feature make it cheaper to do a similar feature in typeof? typeof(List<>.Count)? Saving additional runtime reflection by making typeof work statically on members would be really nice.

[jnm2]

@MgSam I don't think the view is that this is expensive anymore, and my view is that it's straightforward to address the mentioned corners. Back at the time, the corners were coming as an afterthought, but they're priced into my proposal and the implementation ends up as 40 lines of compiler code.

I can't speak to the comparative cost of adding member lookup to typeof, but this nameof work doesn't feel like it leads up to that. Unlike typeof, nameof already does member lookup, and it's being loosened to allow unbound generic types.

[jnm2]

🎉 LDM approved the proposal! A backup plan was also pre-approved. If preferable for implementation, we could do a version of this which did not provide lookup through generic type constraints.