Referencing type members as a MemberInfo instance

[hermankan]

For the following class Foo and method Bar:

class Foo
{
	public Foo() { }
	public int Field;
	public bool Property { get; set; }
	public void Method() { }
}

static void Bar(ConstructorInfo constructorInfo, FieldInfo fieldInfo, PropertyInfo propertyInfo, MethodInfo methodInfo) { }

allow referencing the class members as follows:

Bar(Foo.Foo, Foo.Field, Foo.Property, Foo.Method);

Likewise, referencing Foo could be a shorthand notation of typeof(Foo):

Type fooType = Foo;

This would be compile-time safe, more concise and straightforward than the current ways:

typeof(Foo).GetProperty(nameof(Foo.Property)); // OK
typeof(Foo).GetProperty(nameof(Baz.Property)); // error

Bar<Foo>(foo => foo.Property); // via Expression

I would imagine use cases where reflection is heavily used like this:

Query($"SELECT {User.Id} FROM {User} WHERE {User.Active}=0"); // map to "UIN", "Users" and "Status" respectively

[colejohnson66]

How would these implicit conversion operator-like things work when overloads exist? What is this supposed to do?

ConstructorInfo ci = Foo;

public class Foo
{
    public Foo(int a) { }
    public Foo(string a) { }
}

[Richiban]

Not the OP, but I'd expect that to be a compiler error, in the same vein as:

public static class C
{
    public static void M(string x) {}
    public static void M(int x) {}
}

var f = C.M; // Error: the delegate type could not be inferred

[hermankan]

This should probably fail at compile time. I would go further and propose an extended syntax like Foo.Foo(int) but that would complicate things because there may be another overload Foo(Type type).

Anyway, my primary intent was to allow for at least PropertyInfo for the use case I mentioned.

[HaloFour]

See: #712

"In Foof We Trust"

[hermankan]

Thanks, the memberof() proposal in terms of underlying reasons behind it perfectly matches this one, I find it still verbose though. Correct me if I am wrong but currently member declarations are used only as a delegate, so in all other cases why can't we use them for reflection purposes directly without additional constructs?

Likewise, referencing Foo could be a shorthand notation of typeof(Foo)

I stand corrected, the implicit conversion would cause ambiguity in this scenario:

class Foo
{
	public static bool Method(int x) { }
	public static bool Method(Foo x) { }
	public static bool Method(Type x) { }
}

var m1 = Foo.Method(int); // m1 is MethodInfo
var m2 = Foo.Method(Foo); // is m2 MethodInfo or bool?