LDM Notes for June 11th, 2025

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-06-11.md

Agenda

• Extensions
  • Dynamic resolution of operator true/false
  • Extension operators in LINQ expression trees
  • Built-in operator protection rules
  • Extension module initializers
  • Extension methods as entry points
  • Langversion behavior for new extensions
  • nameof

[KennethHoff]

I don't understand why cref and nameof uses two different syntaxes. If the shorter nameof form is not ambiguous in nameof, why use the longer form in cref. Why introduce two distinct concepts here?

[CyrusNajmabadi]

I don't understand why cref and nameof uses two different syntaxes. If the shorter nameof form is not ambiguous in nameof, why use the longer form in cref.

Nameof references a group of symbols with a particular name. Crefs have to reference individual symbols, which may have no name.

Nameof also literally has no syntax specific to it. It's syntactically an invocation with an expression arg. That's not the case with cref.

Why introduce two distinct concepts here?

The concepts are already distinct, and have been since the introduction of the features.

[jnm2]

Yeah, crefs support multiple syntaxes too like the M: syntax. There's never been a connection between crefs and nameof.

[sab39]

I'm not entirely clear on what the difficult part is about nameof, which makes me think there must be something subtle about how it works that I'm missing. The way I understand it, the result of nameof is always going to be a string that is present verbatim in the source code somewhere between its parentheses, and I think that you can always know what the value must be just based on the syntactic structure of that source code fragment. If so, you do need semantic information to know whether the expression is an error or not, but it doesn't matter if there's ambiguity about what it binds to, because any possible binding would lead to the same string result. nameof(x.y) will always be "y" if it compiles at all, right?

[333fred]

For other things, we make you do ExtensionType.get_Property; this isn't the string you'd want though, as that would give you "get_Property".

[CyrusNajmabadi]

What I mean is - why is nameof special in this regard?

The way nameof works is that it is just a normal invocation with a normal language argument. This then fails to bind, due to their being no actual nameof method in scope. At that point, special nameof logic takes over and reinterprets that whole invocation/argument again with the special semantic rules nameof has.

So we have to define those rules if we want it to work with new language constructs. As today it has no idea how to deal with those constructs :)

Does that help?

[sab39]

What happens to nameof(M) if M is a method group and you rename-refactor just one of its overloads?

[jnm2]

Right, I do think the prior art with nameof and method groups, or renames on attributes, provides straightforward analogies for what should happen with nameof and extensions.

[jnm2]

The difficult part is still there, which is that a rule needs to be put in place to bind ExtensionContainer.InstanceProperty when inside nameof- analogous to binding ClassName.InstanceMember when inside nameof, but it doesn't fall out for free with extensions.