nameof operator

Topics: C# Language Design
Apr 9, 2014 at 10:13 PM
I noticed and was excited about the proposal for a nameof operator in the language feature table. How does this operator relate to the infamous infoof operator? How would it solve some of the issues Eric Lippert brings up here (like overload resolution)? I've read all of the language design notes but I haven't seen this discussed anywhere yet.

Thanks.
Developer
Apr 9, 2014 at 11:32 PM
Those issues just don't arise. nameof(X) resolves to "X", no matter how many overloads there are.

There is an IDE issue of what should happen when you rename one of the overloads - should the IDE change the nameof(X) to refer to the renamed one or not? I don't think we've solved this problem.
Marked as answer by TomasMatousek on 4/18/2014 at 8:32 PM
Apr 10, 2014 at 9:06 AM
Edited Apr 10, 2014 at 9:06 AM
I think when a method has overloads, a popup should ask whether to change just the method, or all the overloads.

Then change the nameof(X) if the user chooses all the overloads.
Apr 10, 2014 at 12:25 PM
Olmo wrote:
I think when a method has overloads, a popup should ask whether to change just the method, or all the overloads.
That's already in option in the rename popup.
Then change the nameof(X) if the user chooses all the overloads.
Sounds reasonable, after all X in this case is the name of a method group. One method in the group is renamed but the method group name remains unchanged so shall X in nameof(X).
Apr 10, 2014 at 12:45 PM
Will nameof give the name however it appears in source code when it is passed into the operator? For example, would nameof(System.Console.WriteLine) and nameof(WriteLine) (after the requisite static import) give different results?
Developer
Apr 10, 2014 at 4:36 PM
In either case the result is "WriteLine".
Apr 10, 2014 at 5:33 PM
It seems like there might be use cases where you'd want the fully qualified name though, no?
Developer
Apr 10, 2014 at 8:38 PM
Sure, there are cases you'd want the fully-qualified name. But then we'd have to solve the hard problems.
Apr 12, 2014 at 8:33 AM
I've been working a lot with reflection in Java, but just a little in .NET. For me, it's very hard to suppose a case when the nameof might be useful. The most common case is picking a method both by name and its parameters types (yes, you must consider the overloads yourself -- not much differs from infoof), where incorrect signature specification fails in runtime. This is commonly a source of live issues if no tests are written, and there's just a little typo. An infoof, I believe, might have a bigger influence on not making mistakes like that, and letting you to be protected by wisdom of your compiler.
Apr 12, 2014 at 8:50 AM
Reflection isn't the only scenario where nameof could be used, there are possibilities:
  • INotifyPropertyChanged - [CallerNameAttribute] help with this but it only works in a property setter. If you want to raise a change notification from an unrelated method then you still have to use specify the property name directly. With nameof you can write OnPropertyChanged(nameof(Foo)) anywhere in the class.
  • Diagnostics - throw ArgumentNullException(nameof(arg));
Yes, it's probably less likely to use nameof with reflection, after all most of the time you use reflection because the name of the property isn't know at compile time. But it still can be useful, for example if you want to generate a LINQ expression which uses known properties:

Expression.Property(x, nameof(Name))
Apr 12, 2014 at 9:58 AM
@mdanes
hm, that's quite interesting, I wasn't aware of it. Thanks for pointing that.
Apr 17, 2014 at 2:02 PM
Edited Apr 17, 2014 at 2:05 PM
Another important scenario are Attributes.

Example:
public class MyClass
{
      public string SomeProperty { get; set; }
   
      // New language syntax with refactoring support:
      [DependsOn(Property = nameof(SomeProperty)] 
      public string Value { get; set; }

      // Old string syntax without any IDE support:
      [DependsOn(Property = "SomeProperty"] 
      public string Value { get; set; }
}
May 6, 2014 at 9:06 PM
I'm a bit confused. Would this nameof operator be as from an article/weblog in '04 or like a question in '06? Or both/neither?
May 7, 2014 at 6:52 AM
@rothdave
yes, that makes sense as far as I remember that attributes must be constant. But I personally think that it's somewhat weak, because it's just a string, and not an object describing the property fully. Roughly speaking, a string can be interpreted in any way.
May 7, 2014 at 7:57 PM
halogen wrote:
@rothdave
yes, that makes sense as far as I remember that attributes must be constant. But I personally think that it's somewhat weak, because it's just a string, and not an object describing the property fully. Roughly speaking, a string can be interpreted in any way.
The compiler knows the exact value at runtime, so it's certainly a candidate for a "compile-time constant". Since there are major upsides to it, including the intended uses, for all I can tell, there's no reason for it not to be treated as a constant value.
Oct 11, 2014 at 5:15 AM
And what about keywords to be used with nameof, like nameof(property), nameof(method), nameof(class), nameof(namespace) and so on to refer to the current context?