nameof special operator names

[davhdavh]

nameof currently only support "obvious" names. but it would be nice if you can also reference operators, indexers etc.
e.g. nameof(myclass.operator==) => 'op_Equality', or
nameof(myclass.implicit) => 'op_Implicit'.
It would also be acceptable to have to give the generated name nameof(myclass.op_Equality) => 'op_Equality', since the main point in my case would be to track usage of code used in IL generation.

[YairHalberstadt]

One of the purposes of nameof is to be able to rename variables/members more easily. Given that these won't change, why not define constants?

[davhdavh]

As I can see it, there is 1 major reasons to use nameof. It enabled much better tooling support for renaming, usage analysis, and other things. Right now it is limited to elements which CAN be renamed, which then obviously limits the usage to renaming, but I don't see why that limitation exists and thus limits what the feature can be used for.

[YairHalberstadt]

What would your use case be? What would nameof give you over Roslyn providing a nuget package with these constants supplied?

[MillKaDe]

@davhdavh

Try this:

public static class Names {
  class Add { public static Add operator + (Add a, Add b) => default; }
  public static string OpAdd => typeof (Add).GetMethods ()[0].Name; // = "op_Addition"
}

[mburbea]

Yeah, I've wanted this before for things like getting the name of indexers.

typeof(string).GetDefaultMembers(); // returns MemberInfo[]{Char Chars[Int32]}
public class F
{
      this[int x]=> 0;
}
typeof(F).GetDefaultMembers() // returns MemberInfo[0]

Unfortunately, I was told tough.

[davhdavh]

@YairHalberstadt

private static readonly MethodInfo _getConversionMethodInfo =
  typeof(BooleanConverter).GetMethod("op_Implicit", ..., null, new[] {typeof(bool)}, null);
private static void EmitConvertFromBool(ILGenerator il) => il.Emit(OpCodes.Call, _getConversionMethodInfo );

Now, if I go to the implicit operator and remove it from code, it will fail at RUNTIME, rather than COMPILE time. If I am diligent and first use the tooling support to check for all usage prior to removing it, I can still not see it is being used anywhere.
It isn't a matter of getting the name, it is a matter of the tools and compilers doing the work for me.

In fact, the reason I made this report in the first place was because i made a constructor private for a class to convert it into a singleton, but that constructor was used in the IL generation. If I had used nameof(class.ctor), I wouldn't have had to deal with that, the compiler would have detected the issue.

[qrli]

nameof gets the name literally in code at compile time, but not from reflection. What you want is the reflection info, which is only provided by reflection at runtime. The reflection info can be different for compile time and runtime because of existence of various IL rewrite tools.

[davhdavh]

@qrli That argumentation is also true for current implementation of nameof, so don't see why that should prevent nameof to cover compiler named entities.

[HaloFour]

The limitations of nameof are largely the result of the team wanting to keep the design simple so that there would not be any syntax changes required to the language. The compiler parses it like a normal method call invocation, and if the nameof method is not in scope that's when the compiler lowers it to a constant of the name of the expression. Anything beyond, such as the proposals here, will require new syntax for forms of expressions that reference those special members.

I'm not saying that these changes shouldn't happen, just giving some backstory as to why nameof works the way it does. I'd personally like it to also support method groups with signatures so that you can explicitly reference a specific overload.

[YairHalberstadt]

I'm not saying that these changes shouldn't happen, just giving some backstory as to why nameof works the way it does. I'd personally like it to also support method groups with signatures so that you can explicitly reference a specific overload

Not to mention open generics: #702