Proposal: memberof operator keyword

[ryantrem]

C# already supports a typeof operator keyword that gets a System.Type for a specified type. However, you get no help from the compiler if you want to do further introspection. For example, once I have the System.Type, if I want to get a method named Foo with one int parameter, then I have to do something like:

MethodInfo methodInfo = typeof(MyClass).GetMethod("Foo", typeof(int));

And unfortunately if I get this wrong, I won't know until runtime.
It would be much nicer if instead I could do something like:

MethodInfo methodInfo = memberof(MyClass.Foo(int));

Using this syntax, members would be have the usual accessibility (e.g. private members would be visible from within a type, public members would be visible outside the type, etc.). Further, we'd have compile time support for this so you'd know right away if you got something wrong, or if the method signature changes after writing your reflection code. Finally, this would work for all member types, and therefore could be used to get FieldInfos, PropertyInfos, MethodInfos, EventInfos, or ConstructorInfos.

[jjvanzon]

propertyof() would be cool too. I could think of a few more. I always felt, that working with reflection, should be as natural to the language, as working with the constructs themselves.

[Joe4evr]

propertyof() would be cool too

Did you not read the final sentence of the OP? 😒

I always felt that working with reflection should be as natural to the language as working with the constructs themselves.

Really? Cause I don't. I recall that Reflection deliberately looks different from normal code because that makes it a giant red flag. It's not supposed to be used willy-nilly.

Furthermore, reflection over members that are already visible at compile-time seems pretty useless to me. The primary uses of reflection are 1) to obtain info from types that are passed into it from assemblies that depend on you, and 2) to obtain values that are not visible at compile time (e.g. private fields).

[DavidArno]

Furthermore, reflection over members that are already visible at compile-time seems pretty useless to me

That was my thought too. I just don't understand all the upvotes for this proposal. Cases where you would do reflection on known types are rare and pretty much limited to "hacks" for accessing otherwise inaccessible types and members. And in cases where the type isn't known at compile-time, the compiler can't help you so memberof would serve no purpose there.

[TahirAhmadov]

I don't think this is accurate. I frequently need to reference methods known at compile time in reflection. For example, if you have a generic method which needs to be invoked using reflection, something like memberof would simplify that greatly. In other cases, you use reflection when some types are unknown at compile time, but others are - it's a mix; having memberof would make such code more elegant, too.

I do agree, though, that this is a little specialized, and more of a scenario for library authors and such, as opposed to general development.

Also, it's easy enough to write helpers which achieve the same from LINQ expressions and/or delegates (in case of methods). But, that introduces a performance hit as said LINQ expression and/or delegate needs to be instantiated. The performance can be improved by using static readonly fields to "cache" these "info" instances (which is what I do today).

[scalablecory]

Using reflection primarily along with code-gen, I can see the use for this. I've wasted a fair amount of time trying to find the specific GetMethod etc. call that'd pull the actual method I'd want.

That said, I'd fully acknowledge that this proposal does not come close to meeting the 80/20 rule.

[ryantrem]

Furthermore, reflection over members that are already visible at compile-time seems pretty useless to me.

As an example of a good use case, consider a dependency injection system. Autofac, for example, is based on factory methods. So you register a component via factory method (pseudo code):

void RegisterComponent(Func<IComponentContext, object> componentFactory)

Now say you have a class Foo with a static factory method that you want to register:

public class Foo
{
    public static Foo Create(A a, B b, C c) { ... }
}

I could register it like this:

configuration.RegisterComponent(context =>
{
    return Foo.Create(context.Resolve<A>(), context.Resolve<B>(), context.Resolve<C>());
});

But this can get very verbose and repetitive. In cases like these, I'd prefer to be able to register a MethodInfo and let the DI system do the work of resolving each dependency:

void RegisterComponent(MethodInfo componentFactory)

configuration.RegisterComponent(memberof(Foo.Create(A,B,C));

Of course I can do this today, but it is verbose and error prone and I get no help from the compiler.

[Joe4evr]

So... Does Autofac not support, say RegisterComponent<Foo>(); and resolve dependencies recursively? Or why you need a factory method to begin with?

[svick]

Previous discussions about this: dotnet/roslyn#1653, dotnet/roslyn#128.

Bot of them were closed by LDM members, they didn't think it makes sense to add this feature to the language.

[alrz]

Related (compiler intrinsics): dotnet/roslyn#11475 (comment)

[Joe4evr]

There's also something good about keeping reflection (mostly) out of the language. You opt into it very explicitly through use of APIs.

Mads backing up what I said about the way reflection is designed.

[HaloFour]

@Joe4evr

I'd somewhat agree, but I do think it's worth having a methodof language keyword that could behave similarly to typeof for the following reasons:

1. Type safety. The compiler can guarantee that the method signature is valid at runtime.
2. Performance. The CLR offers the same mechanism for resolving a method as it does for a type, via ldtoken and a static method call. This would be much more efficient than the best case of the reflection API which has to look up by name, convention and signature at runtime.
3. Simplicity. The reflection API for simple methods is fine, but that API was never updated for generics and simply doesn't work with them. Currently a developer is required to query all of the methods of a type, loop and manually interpret each MethodInfo. It's a pain that requires a minor wall of code in order to write accurately and is inherently error prone as a result. It's also completely unavoidable if you plan on building out expression trees for queryables manually. A language feature could reduce all of that to a single simple expression that doesn't have to jump through any of those hoops.

[alrz]

@HaloFour What is the advantage of this compared to compiler intrinsics?

[HaloFour]

@alrz

I'd have to have to see a proposed function signature. I don't think a compiler intrinsic could produce as neat a syntax as proper language support, but I'd be satisfied if it came close.

[alrz]

Ok, how about this:

MethodInfo methodInfo = ((Action<int>)MyClass.Foo).GetMethodInfo();

GetMethodInfo is an extension method in System.Reflection.

A compiler intrinsics call should be something similar probably with better performance.

[HaloFour]

@alrz

So it would manifest as a method that accepts a System.Delegate? The compiler would then take that method call and translate it into the corresponding ldtoken and call to MethodBase.GetMethodFromHandle method? How would the compiler validate the argument, particularly if I pass in some arbitrary delegate variable?

Such a solution may solve the simple case, same as methodof. However there are still massive gaps in the current API for when a generic type argument might be supplied at runtime via a Type variable. For that I proposed https://github.com/dotnet/corefx/issues/644 and https://github.com/dotnet/corefx/issues/16567 which seem to not be going anywhere. The BCL team doesn't seem to really understand the utility of these methods, which is surprising given the amount of garbage code they had to write within LINQ itself due to the fact that they don't exist.

Update: Fixed references to CoreFX repo issues.

[ryantrem]

So... Does Autofac not support, say RegisterComponent(); and resolve dependencies recursively? Or why you need a factory method to begin with?

Yes, Autofac supports that style of recursive dependency resolution. However, in cases where you have multiple constructors, you need to choose between:

1. Change your class definition (if possible), such as adding an [ImportingConstructor] (not Autofac, but other DI systems) to the one constructor that is intended to be used in the context of a DI system.
2. Use heuristics, such as choosing the constructor with the most parameters that can be satisfied by the DI system (Autofac does this, but in a way that can be hard to predict and control).
3. Use factory methods (what Autofac does at the core, and gives the consumer full control).

Further, if you have a case where a class uses factory methods (I'm not going to go into the details of when and why factory methods are appropriate as that is way too much of a tangent for this thread), then constructor selection heuristics don't help you. If you also are trying to use classes that are not specifically designed to be used in a DI system and you don't want to wrap them to add attributes, then you end up with number 3 from above, which is what I was trying to demonstrate earlier in the thread. In this case, it would be great if the compiler could help me do this (give me language support to select a constructor or factory method that I can pass off to the DI system).

[mattwar]

An equivalent feature has been discussed by the language design team for at least the last decade, known as the "info of" operator, or "infoof, pronounced "in-foof". Its never much got going because of the weight of needing the syntax to describe the signature overloads.

[ryantrem]

That is interesting, thanks for the info @mattwar.

Its never much got going because of the weight of needing the syntax to describe the signature overloads.

Can you expand a bit on this? It seems like the "weight" would be a bit less than the weight of defining signature overloads, and about the same as when calling overloads. That is, if defining a function looks like this:

void Foo(int arg1, string arg2) { ... }

and calling a function looks like this:

Foo(1, "bar")

Then describing a function for an infoof operation like this seems very reasonable to me:

infoof(Foo(int, string))

Is there more that I'm missing?

[HaloFour]

@mattwar

Its never much got going because of the weight of needing the syntax to describe the signature overloads.

I'm not sure I get this argument, though. Sure, it needs some new syntax, but so do most features. The syntax itself is not that complicated. Identifier followed by parenthesis containing a comma-separated list of types. The only thing that I think complicates it is having to determine if that syntax is valid whether infoof or methodof or memberof is a proper function name in the current scope.

This very syntax should already exist. It should have happened for nameof. Instead the team punted and gave us something completely fragile which fails to correctly handle one of the primary reasons for that feature: handling a method rename.

[tuespetre]

@HaloFour good point on the method rename issue... maybe this feature could gain more traction if the 'overload syntax' was implemented and working with nameof. Is there an open issue for that? Is anyone prototyping that? I would love to help 😬

[TonyValenti]

I had an idea regarding the syntax of this:

Memberof(singlemethod)
Memberof<int, string, bool>(overloadedmethod)
Memberof(genericmethod<int, bool>)

[mattwar]

It is a fair argument to make that nameof is nearly all the way to infoof. Maybe with just a little more help. 😁

[HaloFour]

I've tossed a proposal up to argue for overload disambiguation with nameof. I think that syntax would get us most of the way to supporting a proper methodof/infoof.

Would help if I included the link to the proposal: #995

[DenisKudelin]

I would suggest such syntax:

class Foo
{
    public int Bar => this.bar;
    private int bar;
    public int this[string key] => 0;

    public MemberInfo[] GetMembers<T>(bool someValue)
    {
        MethodInfo mi = memberof(this.ToString); // no need to cast
        return new []
        { 
             memberof(this.Bar), 
             memberof(this.bar),
             memberof(this.GetMembers<T>(bool)), // specifying parameter types in case of overloading.
             memberof(string.GetEnumerator), // It works like nameof operator
             memberof(this[string]) // even indexers..
        };
    }
}

Also implementation must not use the search by function name using strings or something like, because it won't work after code obfuscation.

[NMSAzulX]

Cool! I like this.
And propof / fieldof .

[WillSullivan]

I've included a couple examples of why this would be a useful language feature in dotnet/roslyn#31427 might be useful for the discussion. I have a problem understanding why disambiguation is such an overwhelming issue considering that I've never coded a method call (with intellisense guiding me to the overload I'm trying to target) that actually executed on a different overload at runtime. But then I'm a peabrained code monkey not a language designer.

[MillKaDe]

This is my little Reflection helper - which (ab)uses lambda functions and expression trees to do the heavy lifting ...

using System;
using SR = System.Reflection;
using SLE = System.Linq.Expressions;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace My.Util {

  public static class Info {
    public class WrapExpr {
      readonly SLE.Expression expr;
      public WrapExpr (SLE.Expression E) => expr = E;
      public SR.MethodInfo MethodInfo => expr is SLE.MethodCallExpression mce ? mce.Method : null;
      public SR.ConstructorInfo ConstructorInfo => expr is SLE.NewExpression ne ? ne.Constructor : null;
      public SR.MemberInfo MemberInfo => expr is SLE.MemberExpression me ? me.Member : null;
      public SR.PropertyInfo PropertyInfo => MemberInfo is SR.PropertyInfo pi ? pi : null;
      public SR.FieldInfo FieldInfo => MemberInfo is SR.FieldInfo fi ? fi : null;
    } // class WrapExpr
    public static WrapExpr InfoOf<R> (SLE.Expression<Func<R>> lf) => new WrapExpr (lf.Body); // R func ()
    public static WrapExpr InfoOf<T1, R> (SLE.Expression<Func<T1, R>> lf) => new WrapExpr (lf.Body); // R func (T1)
    public static WrapExpr InfoOf<T1, T2, R> (SLE.Expression<Func<T1, T2, R>> lf) => new WrapExpr (lf.Body); // R func (T1, T2)
    public static WrapExpr InfoOf (SLE.Expression<Action> lf) => new WrapExpr (lf.Body); // void func ()
    public static WrapExpr InfoOf<T1> (SLE.Expression<Action<T1>> lf) => new WrapExpr (lf.Body); // void func (T1)
    public static WrapExpr InfoOf<T1, T2> (SLE.Expression<Action<T1, T2>> lf) => new WrapExpr (lf.Body); // void func (T1, T2)
    // 3 and more parameters are left as an exercise to the reader .. ;-P
  } // class Info

  [TestClass] public class _ReflectionHelp {

    public class C {
      public C () { }
      public int F;
      public int P { get; set; }
      public void A1 (int i) { }
      public int F1 (int i) => i;
    } // class C

    [TestMethod] public void _Check1 () {
      var c = new C ();
      var fi = Info.InfoOf (() => c.F).FieldInfo;
      var pi = Info.InfoOf (() => c.P).PropertyInfo;
      var ci = Info.InfoOf (() => new C ()).ConstructorInfo;
      var a1i = Info.InfoOf (() => c.A1 (0)).MethodInfo;
      var f1i = Info.InfoOf (() => c.F1 (0)).MethodInfo;
      Assert.AreEqual (fi.Name, "F");
      Assert.AreEqual (pi.Name, "P");
      Assert.AreEqual (ci.Name, ".ctor");
      Assert.AreEqual (a1i.Name, "A1");
      Assert.AreEqual (f1i.Name, "F1");
    } // _Check1
  } // class _ReflectionHelp
} // namespace

Note, that the body of the lambda function(s) never gets actually called - so its OK to pass bogus arguments to the function calls in the lambda function, as long as the type is correct.

[MulleDK19]

I agree. infoof wouldn't just be useful for performance, refactoring and ease, but it would also help when dealing with obfuscation.

This post will focus mostly on methods.

GetMethod("Foo"); won't do when Foo is then obfuscated, and you'll need to either not obfuscate the name of Foo, weakening the protection, or you'll need to use delegates.

Currently, you can create a delegate of a method and then invoke the Method property on it.

private static void Main()
{
	MethodInfo info = new SomeMethodDel<int>(Program.SomeMethod<int>).Method;
	info.Invoke(null, new object[] { 1, false, 3.14f });
}

private delegate T SomeMethodDel<T>(int a, bool b, float c);
private static T SomeMethod<T>(int a, bool b, float c)
{
    // ...
}

This of course is cumbersome, since you have to define a delegate for each method you need to infoof().
Of course, you can use System.Action1 and System.Func1 for a lot of methods, but these don't support generics, so the example above is one of the scenarios you can't use it.
Both of these give a larger overhead than what you can achieve in pure IL, since in IL you don't need to create a delegate.

Now, I've read the original article by Eric Lippert from 2009 (https://blogs.msdn.microsoft.com/ericlippert/2009/05/21/in-foof-we-trust-a-dialogue), and all his arguments against it are either invalid, or have been ignored when implementing other features, such as delegates.

His most compelling argument against it, in my opinion is overload resolution (pretty much all of his other arguments are about their budget). Imagine this code:

public class Base<T>
{
	public void Bar(int x, int y) { }
	public void Bar(T x, int y) { }
}

public class Child : Base<int>
{
	public Child()
	{
		MethodInfo info = infoof(Bar(int, int));
	}
}

His argument is that this would resolve to Bar(int, int), but he wanted the Bar(T, int) overload (and T is also int).
Quote from Eric's article:

Great. Except that’s not the one I wanted.
I wanted the method info of the second version.
If your proposed syntax picks one of them then you need to give me a syntax to pick the others.

Do I? Because delegates don't, and last I checked delegates ARE in the language.
Imagine this snippet (only the Child constructor is different):

public class Base<T>
{
	public void Bar(int x, int y) { }
	public void Bar(T x, int y) { }
}

public class Child : Base<int>
{
	private delegate void BarFoo(int x, int y);
	public Child()
	{
		BarFoo barFoo = new BarFoo(this.Bar);
	}
}

That's the exact same scenario but with delegates instead. This is a current feature, and this will also pick the Bar(int, int) overload, not the Bar(T, int) overload. And to my knowledge, there's no way to specify the Bar(T, int) overload. The only way to get a delegate for the other is to either use reflection, or remove the Bar(int, int) overload.

So in the end, for methods at least, it's simply a matter of combining delegate declaration and method retrieval.
Recall the first snippet with SomeMethodDel, but now with infoof.

private static void Main()
{
	MethodInfo info = infoof(Program.SomeMethod<int>)
}

private static T SomeMethod<T>(int a, bool b, float c)
{
	return default(T);
}

Here, there's no ambiguity, so it's as simple as infoof(method). But what if someone adds an overload, the infoof would then error. Sure, but that's one of the things's that would make it a great feature. You get compile time analysis. And you're also not prevented from specifying the types even if there's only one overload.

But what if there's only one overload, and someone adds 5 new parameters to it? Now the infoof will still work, and get the changed overload with 5 new parameters.

Sure.
But infoof() wouldn't be the first with that problem. nameof doesn't deal with overload resolution at all, so if you have method Foo(int, int) and Foo(bool, string) and you use nameof(Foo) somewhere to refer to the first overload, and someone then renames that first one to Bar, the compiler can't know which overload nameof was refering to, yet we still have nameof.

Example with overloads.

static void Main(string[] args)
{
    MethodInfo info = infoof(Program.Bar(int)); // Gets MethodInfo of void Bar(int a)
}

private static void Bar()
{
}

private static void Bar(int a)
{
}

How about this, though?

static void Main(string[] args)
{
    MethodInfo info = infoof(Program.Bar(int));
}

private static void Bar(int a)
{
}

private static void Bar<T>(T a)
{
}

This would get the void Bar(int a) overload. How would you get the overload with the generic type? You can't. But neither can you with delegates. Both delegates and infoof would get the void Bar(int a) overload, and like removing that overload would get the overload using a generic type for a delegate, so would infoof.

Quote from Eric's article:

What if overload resolution would have skipped a particular method because it is not accessible?
It is legal to get method infos of methods that are not accessible;
metadata is always public even if it describes private details.
Should we make it impossible to get private metadata, making the feature weak, or should we make it possible,
and make infoof use a subtly different overload resolution algorithm than the rest of C#?

Should we make it impossible to get private metadata, making the feature weak - Are "weak" features bad? nameof also does not work on private members, so is it too a weak feature? If so, why is nameof in the language now? IMO nameof should work on non-public members too.

How about just making public members a priority, and if there's a public member, private members won't be considered at all, in which case a infoofp/pinfoof is required instead.

And instead of infoof it could be methodof, fieldof etc. Sure this could make it sound like its use is fieldof(SomeClass) instead of fieldof(SomeField) which may be confusing, but hell array specifiers are in reverse order, so confusion is nothing new in C#, and typeof gets a type object of a type too, so it makes sense that methodof gets a method object of a method, etc.

Examples:

MethodInfo method1 = methodof(MyClass.Bla);
MethodInfo method2 = methodof(MyClass.Bla(int, bool));
MethodInfo method2 = methodof(MyClass.Bla(bool));
MethodInfo method2 = pmethodof(MyClass.Bla(bool));
FieldInfo field1 = fieldof(MyClass.a);
FieldInfo field2 = fieldof(MyClass.b);
FieldInfo field2 = pfieldof(MyClass.c);
MethodInfo indexer1 = indexerof(MyClass[int]);
MethodInfo indexer2 = indexerof(MyClass[string]);

Note the lack of propertyof. While it'd be nice, there's no way to retrieve a PropertyInfo from a metadata token (nor get a metadata token of a property).

ECMA-335 I.8.10.3
Fundamentally, properties and events are constructs of the metadata intended for use by tools
that target the CLI and are not directly supported by the VES itself.

[TonyValenti]

I saw a post somewhere that said the reason this doesn't exist is because it would require new syntax. What is it that makes this need new syntax?

[svick]

@TonyValenti Overload resolution. Look at some of the examples above, like methodof(MyClass.Bla(int, bool)) or indexerof(MyClass[string]). Both of those are new syntax.

[TheConstructor]

@svick but as stated, we could start without overload resolution and then extend it later. I definitively would love to have this.