Some shortcut character & for nameof inside "$" interpolation

[neurospeech]

I find nameof being too verbose and big... if there is some simple character to replace it, it would be nice... like..

new Binding( Path = $"{nameof(Button)}.{nameof(Button.Command)}" );

can be written as
new Binding( Path = $"{&Button}.{&Button.Command}" )
or
new Binding( Path = $"{&(Button.Command)}" );

If compiler will output as following,

             &ClassName --> "ClassName"
             &ClassName.MemberName --> "MemberName"
             &(ClassName.MemberName) --> "ClassName.MemberName" // very useful for Xaml Binding

These are very small compared to nameof

---

The problem is when we have multiple cascaded nameof operators... for example,...

 img.SetBinding(Image.WidthRequestProperty, 
      new Binding($"{nameof(AtomListViewCell.OwnerListView)}.{nameof(AtomListView.ItemIconWidth)}") 
       {
             Source = this
       });

      // what I am interested is...
 img.SetBinding(Image.WidthRequestProperty, 
      new Binding("OwnerListView.ItemIconWidth") 
       {
             Source = this
       });

So many extra code. It is also little difficult to read.

[lachbaer]

The & operator already exists in C#.
The nameof() operator is not used too much and I find it better if it is a bit more explanatory than having a shortcut. However your suggested shortcut being used in an interpolated string (Path = $"{&Button}.{&Button.Command}) appears really nice to me.

[jjvanzon]

@lachbaer:

The nameof() operator is not used too much [...]

I disagree. I use nameof for more and more stuff. Data binding using strongly typed names instead of strings, put names in exception messages more easily, that change along with rename refactorings, use names as validation message keys, reference MVC actions with nameof instead of literal strings. I used to have a lot of static classes with string constants. I have built whole frameworks around expression trees. Now the nameof operator does the job in most of the cases. I use it more than the other 'of' operators, such as typeof and sizeof and can totally understand the value of shorthand for this. But indeed it conflicts with the address of operator &, which is good of you to point out. I think we easily overlook that, because most of us don't program a lot of unsafe code. So a different character would be a good idea.

[neurospeech]

@janjoostvanzon I tried to look all characters, didn't find any suitable character.

@lachbaer

Usage of nameof

1. WPF Binding, in creating Dependency Properties, you are passing name of property as string literal in Create method

2. Same as point 1 for Xamarin and Windows Phone and now UWP

3. MVC actions

4. Entity Framework Code First, as shown below.. in Table attribute, in ForeignKey attribute, in InverseProperty attribute.

      [Table(nameof(Customer)+ "s"]
      class Customer{ ....  }
   

5. Exception or any kind of logging

6. Prime benefit is, refactoring. If you change name of property, every literal with nameof will change.

[lachbaer]

@neurospeech Thanks for the clarification :-) I haven't seen it being used too much, yet. Maybe, because it still isn't a very old feature ;-) Used it sometimes myself, though.

Can't the $ symbol be reused for that? ${ClassName.Member} for inline code (${ is the starting token) and within string interpolation. I mean nameof is kind of a string interpolation anyway.

[svick]

@lachbaer I think it would be very confusing if ${ClassName.StaticMember} and $"{ClassName.StaticMember}" were both valid expressions and meant something different.

[lachbaer]

$[ClassName.StaticMember]?

[HaloFour]

In designing the nameof feature the team expressed wanting to keep the syntax within the current rules so not to have to introduce any new grammar. All of the proposed syntaxes above would need their own spec. Also, while the feature is useful, especially with specific frameworks, I don't think that it's so common as to justify a shorthand that can only save ~5 characters without introducing other benefits. nameof tells you exactly what the operator does.

[lachbaer]

@neurospeech Why have you closed so early?

If the occurances of nameof are so vast nowadays, then it could be that the C# team has overlooked its real importance. Saving 5 characters seems little, but if used frequently, maybe even in one line of code, it can have a huge impact on reading and overviewing the written code.

[neurospeech]

@lachbaer I closed based on @HaloFour 's comment, but yes you are right, I am writing most of Xamarin and EF Code First and I use nameof extensively, there are at times, multiple cascaded nameof creates confusion in reading code.

For example,

 img.SetBinding(Image.WidthRequestProperty, 
      new Binding($"{nameof(AtomListViewCell.OwnerListView)}.{nameof(AtomListView.ItemIconWidth)}") 
       {
             Source = this
       });

// what I am interested is...
 img.SetBinding(Image.WidthRequestProperty, 
      new Binding("OwnerListView.ItemIconWidth") 
       {
             Source = this
       });

But you see, I have so many extra characters.

[CyrusNajmabadi]

"&" could actually be used, even though it already has meaning in C#. After all, w were able to add nameof(...) even though that already had meaning in the language. We just follow the rule that the existing interpretation beats the new interpretation if the existing interpretation is viable.

So, for example, & could be used if it was in a unary context, but not in unsafe code.

That said, we also have to balance that compat concern with readability. It might be very confusing for people to see "&foo" and go "wait... this code is going unsafe stuff??".

[HaloFour]

It would be ambiguous in the following context, where it is already legal code:

string s = $"{condition&&Control.Text==text}";

Also, I don't understand limiting this proposal to interpolated strings? I'd argue that of the more common places to use nameof would be attributes where interpolated strings are not permitted as they are not constant expressions.

[jnm2]

(@lachbaer btw it's silly but "oversee" and "overlook" have very different meanings.)

[lachbaer]

(@jnm2 Thanks, mixing those words up is a common mistake for Germans, because of their literally different meaning of very similar german words, übersehen, überblicken. I hope my statement above makes more sense now? Btw, it's a nice example how easy somebody can be mistaken by accidentally choosing the incorrect words 😉)

[jveselka]

I think most of the use cases where things are messy are chained nameofs like $"{nameof(Button)}.{nameof(Button.Command)}".
It could be solved perhaps more elegantly by the introduction of $"{{fullnameof(Button.Command)}". There was a proposal in roslyn repo dotnet/roslyn#14474

[alrz]

Why not use the dollar-sign itself?

new Binding(Path = $"({$Button.Command})");

I think we can also use it outside string-interpolations,

switch (name) {
  case $Method1: break; // case nameof(Method1):
  case $Method2: break; // case nameof(Method2):
}

Perhaps we could use the "verbatim" mode to produce qualified names:

var str = $Class.Method; // "Method"
var str = $@Class.Method; // "Class.Method"
var str = $@Namespace.Class.Method; // "Namespace.Class.Method"

etc.

[jnm2]

@lachbaer That's cool, didn't know that about German!

[lachbaer]

Why not use the dollar-sign itself?

I had exactly the same idea last night, except for the '@' solution. '$' itself means "string" in other languages and it is used in C# for strings as well now. Even without the exact knowledge of that 'operator' I would imply from the context that the directly following expression will probably be somehow stringified.

[DavidArno]

A possible symbol would be #. Seems appropriate to use "the symbol with a thousand names" as nameof. Having said that, nameof really isn't hard to type and is way more readable than #, so downvoting this proposal.

[lachbaer]

If one of the problems is to produce fully or partly qualified names, how about extending the nameof operator?

var str = nameof(Class.Method); // "Method"
var str = nameof(Class.Method, class); // "Class.Method"
var str = nameof(Class.Method, namespace); // "Namespace.Class.Method"

Or just levels, in case of nesting:

var str = nameof(Class.Method, 2); // "Namespace.Class.Method" - 2 'points'

Or indeed a leading character:

var str = nameof($Class.Method); // "Class.Method", exactly as written
var str = nameof(@Class.Method); // "Namespace.Class.Method", always fully qualified

There must be a solution to this that has broad support and acceptance, if nameof is really used that much?

[thargol1]

I like the nameof(name, nestinglevel) syntax as suggested by @lachbaer . It's backward compatible, doesn't introduce a new keyword and it allow for arbitrary nesting levels.

Example:

namespace Test
{
	public class MyClass
	{
		public void MyMethod(string myParam)
		{
			Console.WriteLine(nameof(MyMethod)); // Writes "MyMethod".
			Console.WriteLine(nameof(MyMethod, 0)); // Writes "MyMethod"
			
			Console.WriteLine(nameof(MyMethod, 1)); // Writes "MyClass.MyMethod"
			Console.WriteLine(nameof(MyClass) + "." + nameof(MyMethod)); // current way, same result, more code 

			Console.WriteLine(nameof(MyMethod, 2)); // Writes "Test.MyClass.MyMethod"
			Console.WriteLine(nameof(MyMethod, 3)); // Writes "<projectname>.Test.MyClass.MyMethod"
		
			Console.WriteLine(nameof(myParam, 2)); // Writes "MyClass.MyMethod.myParam"

			Console.WriteLine(nameof(MyMethod, 4)); // Compiler error or not ?? it could also write the maximum nesting level possible up to 4.
			Console.WriteLine(nameof(MyMethod, -1)); // Compiler error !
		}
	}	
}

In my humble opinion this could work better than #701.

I use nameof a lot for debugging and logging.

[joelmdev]

"&" may not be the way to achieve this, but I too would like to see some shorthand for nameof in string interpolation. We use this quite a bit in exception messages and logging, and it can be quite kludgy if you need 2 or 3 nameofs in a single sentence. Surely we can find a character with which a term can be surrounded that doesn't cause syntactic conflicts.

[canton7]

Unless I've missed it, noone's mentioned the proper solution for this exact use-case (in WPF at least)...

new Binding() { Path = new PropertyPath(Button.CommandProperty), ... }

You can also do funky things like placeholders using (n), such as:

new PropertyPath("(0).(1)", SomeType.SomeProperty, SomeOtherType.SomeOtherProperty)

Sadly this very powerful feature is only mentioned in passing in the docs for PropertyPath.Path.