Proposal: fullnameof operator

[dsaf]

Migrated from: dotnet/roslyn#14474 and dotnet/roslyn#7973

A well-know one, not much to add.

Doing this currently which is not amazing:

public static class Extensions
{
    public static string fullnameof<T>() => typeof(T).FullName;
}

using static Extensions;

Console.WriteLine(fullnameof<SampleClass>());

[jnm2]

If we do this, fullnameof should return the C# language name, not the CLR type name (to the extent that they differ). That is the current philosophy behind nameof and I see the value. For example, Foo not Foo`1 or Foo`1[System.Int32].

In other words, it should return what you type in C# to refer to the object, not the CLR representation.
This matters with nested classes because in C# you don't write Namespace.ContainingType+NestedType; you write Namespace.ContainingType.NestedType.

[mwpowellhtx]

@jaredpar I'd expect it to be consistent with nameof which returns the alias name IIRC. nameof(int) is not allowed, either.

Is System.Int32 the same as int in this instance? I don't know. Assuming a less contrived illustration, of course.

[jaredpar]

My intuition would lean more towards making fullnameof(somealias) a warning / error. The logic being that if you wanted the simple name then you can use nameof. Using fullnameof here means you likely didn't realize it was an alias or mistakenly thought it would apply to the underlying type

[foxesknow]

Does it have to return a string? Why not return a struct with various properties. For example:

Console.WriteLine(fullnameof(Example).Alias);  // Example
Console.WriteLine(fullnameof(Example).Name);  // Int32
Console.WriteLine(fullnameof(Example).LanguageName);  // Int

[IanKemp]

Does it have to return a string? Why not return a struct with various properties. For example:

Console.WriteLine(fullnameof(Example).Alias);  // Example
Console.WriteLine(fullnameof(Example).Name);  // Int32
Console.WriteLine(fullnameof(Example).LanguageName);  // Int

Because that's unnecessary complexity. If you want that information, use reflection.

[KalleOlaviNiemitalo]

Current behavior of nameof:

namespace Demo;
using Hah = System.Int32;

class @new
{
    const string name1 = nameof(@new); // means "new", not "@new"
    const string name2 = nameof(Hah); // means "Hah", not "Int32"
    const string name3 = nameof(System.Func<int>); // means "Func", not "Func`1"
    const string name4 = nameof(@new.Finalize); // means "Finalize", not "~@new"

#if false
    const string bad1 = nameof(operator +); // error CS1041
    const string bad2 = nameof(op_Addition); // error CS0571
    const string bad3 = nameof(~@new); // error CS0119
    const string bad4 = nameof(~@new()); // error CS1955
#endif

    public static @new? operator +(@new? a, @new? b) => null;

    ~@new() { System.Action act = this.Finalize; }
}

Direct calls to Finalize methods are blocked by error CS0245, but this.Finalize is a valid expression convertible to a delegate, so it seems OK that the value of a nameof expression can be "Finalize" as a C# language name.

The "new" vs. "@new" distinction makes me wonder whether fullnameof(global :: System . Int32) should be "global::System.Int32" or just "System.Int32". It should surely omit unnecessary whitespace, though. Inspired by dotnet/csharpstandard#193.

[jjvanzon]

I feel uneasy promoting my own framework here, but I made something for this a long time ago. It isn't perfect, but it will handle many common cases. You can call:

ExpressionHelper.GetText(() => myVariable.MyList[i].MyProperty);

And get "myVariable.MyList[i].MyProperty" out.

It won't cover full type names, though. I had something for that too, but I never ported it to my current code base.

https://github.com/jjvanzon/JJ.Framework/blob/master/Framework/Reflection/ExpressionHelper.cs
https://github.com/jjvanzon/JJ.Framework/blob/master/Framework/Reflection/ExpressionToTextTranslator.cs

[jnm2]

@janjoostvanzon That's really cool! Now if only it was a compile-time constant and could be used in an attribute...

[jjvanzon]

@jnm2 That's what I thought when I made it. That would give better performance, even though I did try to make it perform well without sacrificing reliability. Still it cannot be faster than a literal string.

[alrz]

@dsaf

There is a proposal to make typeof(T).FullName a compile-time constant (dotnet/roslyn#10972). Does that cover your use cases?

Also #522 suggests to add a shorthand for nameof(Class.Method), e.g. $Class.Method, I'd added to that that we can use [email protected] to produce a string as it appeared in the source (#522 (comment)).

[jehrenzweig-captionhealth]

dotnet/roslyn#10972 has been marked "Closed as not planned".

[dsaf]

@alrz not really as it would be nice to be able to refer to sub-namespaces and members as well (yes, I remember dotnet/roslyn#1653).

I am mostly after shortest possible syntax but compile-time evaluation is also important.

[alrz]

it would be nice to be able to refer to sub-namespaces and members

[email protected] would allow that too, yes it does require to spell out all required parts but I don't think we can make it any shorter without losing flexibility.

[Meai1]

This stuff is ridiculous, an extra keyword just for something small like this? just add a method like Class.fullnameof

[HaloFour]

@Meai1

The point of it being a keyword is that it could be used as a constant. Invoking a method on the Type class doesn't result in a constant string and thus can't be used in something like an attribute.

I believe there is a separate proposal for having the compiler consider certain expressions on typeof(T) as constants, e.g. typeof(Foo).FullName.

[Meai1]

ok but this really sounds more like a problem about c# attributes. Why else require all these new keywords

[HaloFour]

@Meai1

The arguments used in attributes are required to be constants and embeddable directly in the assembly metadata. That is a limitation of the CLR and not specifically of the C# language. When the CLR actually instantiates the attribute it expects that the embedded constant matches the type of the constructor parameter or property so the C# compiler can't embed any alternatives, let alone something that represents an expression to be evaluated at runtime. The best the C# compiler could do is to introduce a form of constant expressions (constexpr) which could be evaluated at compile time and their result directly embedded.

[rummelsworth]

This would be mighty convenient in some cases, especially when defining an EventSource subtype.

I'm currently doing this:

        // I'm repeating the full namespace in each case, even though I don't strictly need to, for better safety if/when refactoring moves things around.
        [EventSource(Name =
            nameof(Company) + "." +
            nameof(Company.ProductUmbrella) + "." +
            nameof(Company.ProductUmbrella.Product) + "." +
            nameof(Company.ProductUmbrella.Product.Feature) + "." +
            nameof(Company.ProductUmbrella.Product.Feature.Module) + "." +
            nameof(Company.ProductUmbrella.Product.Feature.Module.ETWEventSource))]
        public class ETWEventSource : EventSource
        {

I'd be delighted to be able to do this:

        [EventSource(Name = fullnameof(ETWEventSource))]
        public class ETWEventSource : EventSource
        {

[IanKemp]

This should work for namespaces too!

I.e. fullnameof(Full.Namespace.Name) = Full.Namespace.Name

[CyrusNajmabadi]

If we do this, fullnameof should return the C# language name, not the CLR type name (to the extent that they differ). That is the current philosophy behind nameof and I see the value. For example, Foo not Foo1 or Foo1[System.Int32].

How does this work with generics?

[npodbielski]

This would be most usable in Obsolete attribute.
[Obsolete("use "+fullnameof(NewClass.NewMethod)+" instead.")]
For now this is necessary to use
[Obsolete("use "+nameof(NewClass) +"." + nameof(NewClass.NewMethod)+" instead.")]
Which is a really tiresome for few dozens of members.

[HaloFour]

I'd be happy if typeof(String).Name and typeof(String).FullName could be considered constant values evaluated by the compiler.

[mwpowellhtx]

Perhaps a corollary to this one, I have a case where namespaceof would also be interesting. i.e.

namespace Foo
{
    class Bar { }
}

// ...

const string barNameSpace = namespaceof(Bar); // "Foo" const string

I mean, if we can discover nameof as a const string, I imagine it would not be that difficult to do a similar thing for its namespace.

[Rabadash8820]

It would also be nice if the character(s) separating the parts of the identifier's fully-qualified name could be configured (rather than using Split/Join after, as that would prevent using the string in contexts that require a const string). See my other discussion #5483 for a motivating example in the Unity game engine (sorry I didn't see this Discussion before posting 😅). Something like the following, where the second argument to nameof would indicate both the request for a fully-qualified name, and the character (or any const string?) that should be used to separate the identifier's parts:

namespace Foo.Bar {
    class Baz {
        void DoStuff() { }
    }
}
// ...
nameof(DoStuff, '/')    // Returns Foo/Bar/Baz/DoStuff

[HaloFour]

IMO this feels like a transformation that would be very niche and not a good candidate for a language feature. I'd rather it be considered as a use case for constant expressions.

[Rabadash8820]

@HaloFour Fair point (my motivating Unity example is certainly a bit niche).

I'd rather it be considered as a use case for constant expressions.

Do you mean that you'd rather keep the original proposed fullnameof syntax, so that it can be a const expression, or is there some new "constant expression" proposal in the works for which you think my proposed optional-arg syntax would be a good use case?

[HaloFour]

I'd rather a different language feature that would enable certain expressions, including function invocations, to be evaluated by the compiler during compile time and the result treated as a constant. Then you can use that expression as an argument to an attribute or the like. The compiler already supports this in trivial cases like 2 + 2 or "Hello" + "World".

See: #1028

[Rabadash8820]

Oooh, yeah I like the discussion on #1028 a lot. 🤤 If something like that comes to fruition, then my use case would just be string.Join('/', fullnameof(Identifier).Split('.')), and the expression would still magically be a compile-time constant usable in attributes. Fingers crossed for that proposal!! 🤞

[mwpowellhtx]

I might analyze this vis-a-vis Attributes being one use case. Can probably learn a lot from that why "expressions" are not allowed, at compile time, for instance.

[Flithor]

I suggest add a new operator called stringof
It will turn the "orignal string in code" in this operator as a string when compilating.
The "orignal string" in this operator will be management by syntax check and supports IntelliSense, simile to nameof.

example:

stringof(MyNamespace.MyClass)
// => "MyNamespace.MyClass"
stringof(MyClass.MyMethod)
// => "MyClass.MyMethod"
stringof(MyClass.MyMethod(string, int))
// => "MyClass.MyMethod(string, int)"

[KathleenDollard]

I just upvoted this because of a particular source generation problem.

(edit: @CyrusNajmabadi pointed out that you can get the value entered via the SyntaxNode. I'd still like this feature, but it is no longer blocking - further comment below)

(The use case here is extending System.CommandLine Dragonfruit, especially to subcommands. Each method represents a command, each parameter an option or argument. The generation creates types for the commands, and if the method is named Main and there is no entry point, creates the entry point. This is the way Dragonfruit works today, except it does not have subcommands and generation is done in an MSBuild target.)

I need to link a bunch of methods together. The syntax I like best puts the name of the subcommand method in a params array on the attribute:

using DragonFruit2;
using Mine;

public class Program
{
    [CliCommand(nameof(Sub1), nameof(Foo.Sub2), nameof(Foo2.Sub3))]
    private static void Main(int x, int y)
    {
        // work here
        Console.WriteLine($"x, y: {x}, {y}");
    }

    public static void Sub1(){}
}
public class Foo
{
    public static void Sub2(){}
}
namespace Mine
{
    public class Foo2
    {
        public static void Sub3(){}
    }
}

If we fullnameof, I believe this would work great. Without it, there is no realistic way to make this syntax work. The popularity of Dragonfruit is specifically that there is no ceremony and this adds just enough to describe what is going on.

To make generation more efficient, I would love it if we carried the symbol pointed to by fullnameofi n the attribute parameter symbol rather than a typed constant. That would avoid a name lookup. But at least with the proposal as stated I could do the lookup. I am not concerned about backwards compatibility because fullnameof is all lowerase. I am only a little concerned about inconsistencies in the symbols between nameof and fullnameof (if fullnameof included the symbol reference it was pointing to) because fullnameof is specific and nameof is not.

[KalleOlaviNiemitalo]

Could the source generator examine the syntax tree and understand that nameof(Foo.Sub2) refers to the method in Foo, regardless of what the nameof operator means in the C# language?

[CyrusNajmabadi]

It definitely could.

[KathleenDollard]

@CyrusNajmabadi I found the nameof to be the constant string that was the name (without the type). I would love to solve that - I definitely could have overlooked something.

[KathleenDollard]

Yep, thanks to @CyrusNajmabadi I checked my work and I did overlook something and have this fixed.

If I require that all methods be in the current namespace or fully qualified (I think I have to check for both if the first fails), I can get the fully qualified name and do the lookup it appears.

I would still like to see this feature, but I am unblocked.

Thanks again!!

[333fred]

@KathleenDollard you can just use semantic info from your generator, rather than using the constant value.

[CyrusNajmabadi]

Yup. You have full access to the syntax and semantics. There's no requirement to use the exact constant value the compiler determined.

[KalleOlaviNiemitalo]

@KathleenDollard have you published the prototype somewhere?

[TimothyMakkison]

Edit

Like many people in this thread I wanted a way of converting chained member access into a string. nameof is almost perfect for my needs by providing a syntax highlighed, refactoring friendly, ide supported way of writing a path. Unfortunately it only returns the final leaf node of the path provided.
Note this is not constant at compile time and is not meant to be a replacement for OPs suggestion. Hopefully the follwing code could provide a convenient way to create configuration for reflection and source generators.

.NET 6 added CallerArgumentExpression which lets you create a workaround version of stringof or fullnameof.

Example

using System.Runtime.CompilerServices;

// value: "value"
// fullpath: "nameof(HttpResponseMessage.Content.Headers)"
var fullString = StringOf(nameof(HttpResponseMessage.Content.Headers));

// Prints: HttpResponseMessage.Content.Headers
Console.WriteLine(fullString);

// Print the namespace
// Prints: System.Net.Http.HttpRequestMessage.Content.Headers
Console.WriteLine(FullNameOf(nameof(System.Net.Http.HttpRequestMessage.Content.Headers)));

static string StringOf(string value, [CallerArgumentExpression(nameof(value))] string fullpath = default!)
{
    // Do some validation here...

    string outputString = fullpath.Substring(fullpath.IndexOf("(") + 1, fullpath.IndexOf(")") - fullpath.IndexOf("(") - 1);

    return outputString;
}

Attribute

// Example usage, do something to Car.Make.Id
[Target(nameof(Car.Make.Id)]
public static partial Car DoSomething(Car car);

[AttributeUsage(AttributeTargets.Method, AllowMultiple = true)]
public class TargetAttribute : Attribute
{
    public TargetAttribute(string target, [CallerArgumentExpression(nameof(target))] string fullpath = default!)
    {
        // Do some validation here...

        // Strip "nameof(" and ")"
        var strip = fullpath.Substring(fullpath.IndexOf("(") + 1, fullpath.IndexOf(")") - fullpath.IndexOf("(") - 1);
        FullPath = strip;
    }

    // Use for reflection or source generator
    public string FullPath { get; set; }
}

[CyrusNajmabadi]

Not the point re: nameof, and I think that is obvious. OP called for, which I agree, something analog to that, evaluates to a compile time

Nothing in the OP mentions anything about a constant. Note: i think having a constant would be nice. But that's an additional concern not actually presently stated there.

[mwpowellhtx]

Well it is basically stagnant for 5 years. Pretty sure it is not happening. So IMHO this is next best thing.

Right, fair enough. But I would not confuse it as even a passable solution for the plethora aforementioned reasons.

Goal there would be for the const string compile time evalution.

[i-e-b]

7 years, and this work-around doesn't support netstandard 😦

[Flithor]

@mwpowellhtx maybe? #701 (comment)

[mwpowellhtx]

@mwpowellhtx maybe? #701 (comment)

Or not. Preferably without having to add 3P bolt on solutions such as analyzers.

[hez2010]

Why not reuse the current operator we already have?
Instead of fullnameof(Foo), we can allow passing constant args to nameof. For example, nameof(Foo, fullName: true), or even nameof(Foo, true)

[colejohnson66]

I'm not a fan of nameless optional booleans, and nameof(Foo, true) fits that. Because now nameof(Foo) and nameof(Foo, false) mean the same thing. nameof(Foo, fullName: true) would work, but it's too wordy, and doesn't address the optional behavior of it.

[KieranDevvs]

Because now nameof(Foo) and nameof(Foo, false) mean the same thing.

What's wrong with that? Its kinda the whole point of optional arguments. And if you dont like it being nameless, then fully qualify it as @hez2010 already did: nameof(Foo, fullName: true)

[TheBrambleShark]

Because now nameof(Foo) and nameof(Foo, false) mean the same thing.

What's wrong with that? Its kinda the whole point of optional arguments. And if you dont like it being nameless, then fully qualify it as @hez2010 already did: nameof(Foo, fullName: true)

If you have "foo. bar".Split('.', StringSplitOptions.TrimEntries); then even without naming the second parameter it's immediately apparent what the parameter is doing.

Conversely, a hypothetical "foo. bar".Split('.', true); that does the same thing (optional boolean property indicating whether or not to trim the entries), is only obvious if you are familiar with the operation.

As for the topic on hand, fullnameof(Foo) is self documenting. nameof(Foo, true) could mean just about anything, and nameof(Foo, fullname: true) doesn't really help because not everyone will use named parameters. If you were unfamiliar with the overload and looking over someone else's code that doesn't use the named parameter, you would likely have some degree of confusion as to what it actually does.

If we were to do the second parameter approach, I would prefer an enum, like nameof(Foo, NameOfOptions.FullName), which is at least self documenting. But that's a whole new type being introduced when that information could be provided via the keyword.

[KieranDevvs]

If you were unfamiliar with the overload and looking over someone else's code that doesn't use the named parameter, you would likely have some degree of confusion as to what it actually does.

Nameless optional parameters are used everywhere in the language. .ConfigureAwait(false) for example, is used heavily.

doesn't really help because not everyone will use named parameters.

That argument could be used for literally any language feature and we would add nothing to the language. Just because someone might not follow good practices, is no reason to not add the language feature. Take lambdas for example, you don't have to name arguments anything meaningful yet lambdas are heavily used language feature.

MyMethod((guessWhatThisIs) => guessWhatThisIs % 2);

Or literally any time you pass null as an argument...

// What is null?
MyMethod(param1, null, param3);

Would an enum be better?... maybe its worth the extra type? but lets not pretend like nameless parameters is some how a blocker for the design of this.

[IanKemp]

Over seven years later and another basic language ask that is still not implemented, I'm sure the team will as usual justify it with "not enough interest" as they usually do for things that in reality they CBA to work on. Meanwhile Mapperly, and I imagine other projects, are coming up with their own implementations to cover for the lack of this simple yet important feature... I can guarantee that different projects will choose different ways of doing this and we'll end up with a fragmented ecosystem for no good reason.

If you don't want to implement this feature, how 'bout you hire some people who do? It's not as if you're working for a scrappy startup that can't afford to hire developers.

[mwpowellhtx]

Probably not along the lines of T``0 or whatever such similar representations tend to be. My two 💵 .

[jnm2]

That would be a departure from how nameof works. nameof gives the C# class or alias name, not the metadata name.

[jnm2]

If there was a chance of the C# compiler allowing typeof(X).FullName as a constant in attributes, that would feel the clearest and cleanest to me.

[whoisj]

typeof(T).FullName being constant would be amazing.

fullnameof(x) is interesting because for members it would be <namespace>.<type_name>.<member_name> but for parameters we'd need something new. <namespace>.<type_name>.<method_name>::<parameter> or something?

[jnm2]

Okay, let's do it! #8505

Please fill in with both use cases for constant typeof(...).FullName as proposed, as well as use cases for other variants like fullnameof which would behave differently, such as by allowing referencing things that aren't types, or by handling generics or nested type separators differently. If there are a lot of concrete use cases that typeof(...).FullName can't help with, that will be good to know.

[jnm2]

I'm proposing making typeof(...).FullName a constant, which will help with some of these use cases: #8505

It would be great to hear in that thread about real-world use cases that support doing this, as well as real-world use cases for fullnameof that aren't addressed by that proposal and don't have a good solution today.

Spoiler: rejected!

[CyrusNajmabadi]

Yes. This would only be for cases where the static information was enough to construct exactly the same string that would be computed at runtime. This would also require runtime to be ok with typeof(...).FullName never changing for that set of types.

[HaloFour]

I edited my comment to not use generic syntax typeof(T).FullName as obviously that would be a case where the compiler could not treat the expression as a constant. :)

[mwpowellhtx]

Well like I said, typeof(T) yields a Type instance. So anything down range of that, would need to be the constant. Probably gonna ruffle some feathers with that proposal.

[HaloFour]

Yes, and the compiler will completely skip those steps, based on the assumption that for any given typeref token that the namespace and type name will always be the same. That's not true of every property of Type, so this can only apply to a few select properties, such as FullName and Namespace.

[whoisj]

maybe instead of changing typeof(T) we add something like typename(T)?

[EtiTheSpirit]

This is a late reply giving more support to this proposition.

I'm getting tired of writing long and complicated messages for my development like $"{nameof(SomeProperty)} does nothing when {nameof(SomeType)}.{nameof(SomeType.SomeOtherProperty)} is set."

However this also raises a problem, which is to what extent the name is written out. Like in my use case, I don't want the namespace, only the class. An earlier comment suggested stringof() for this purpose which would work well for me.

[Flithor]

I've found this:
https://marcinjuraszek.com/2017/05/adding-matt-operator-to-roslyn-part-1.html
https://marcinjuraszek.com/2017/05/adding-matt-operator-to-roslyn-part-2.html
https://marcinjuraszek.com/2017/06/adding-matt-operator-to-roslyn-part-3.html

Perhaps stringof that could be done with a custom analyzer?

[KalleOlaviNiemitalo]

I imagine one could define fullnameof as a static overloaded method, access it via global using static, and use the "interceptors" feature in a source generator to replace each of its calls with a different call that returns the appropriate string. However AFAIK:

• The resulting strings would not be constant expressions like nameof makes.
• fullnameof(Object.ToString) and similar things, where you have a type name and the name of an instance method, would not work because the original method call being intercepted is not valid.
• There might be difficulty with using fullnameof with pointer types, which are not permitted as type arguments and thus would not be covered by a single static string fullnameof<T>(T arg) method. Maybe one could fix that by also generating additional methods; but I don't remember whether Roslyn requires them to be declared before the source generator runs.

If the syntax were full(nameof(expression)) instead, I think that would be easier to implement in a source generator, because the nameof part would allow instance members and squash all types to string so one static string full(string) method would suffice. The source generator would still see what's in the expression of nameof and would be able to generate the result value of the interceptor accordingly. The name full would have a higher risk with clashing with some other declaration, though.

[tb-mtg]

  public static string FullNameOf<T>(int parentLevel = 0) {
      if(parentLevel < 0)
		  parentLevel = 0;
      Type t = typeof(T);
      var fullName = t.FullName;
      var fullNameLastIndex = NthLastIndexOf(fullName, ".", parentLevel + 1 );
      return fullName.Substring(fullNameLastIndex + 1);
  }
	
  public static int NthLastIndexOf(string source, string value, int n){
    if (string.IsNullOrEmpty(source) || string.IsNullOrEmpty(value) || n <= 0)
        return -1;
    int index = source.Length;
    for (int i = 0; i < n; i++)    {
        index = source.LastIndexOf(value, index - 1, StringComparison.Ordinal);
        if (index == -1)
            return -1;
    }
    return index;
  }  

Console.WriteLine(FullNameOf<System.Data.IDbConnection>());   //            IDbConnection
Console.WriteLine(FullNameOf<System.Data.IDbConnection>(0));  //            IDbConnection
Console.WriteLine(FullNameOf<System.Data.IDbConnection>(1));  //       Data.IDbConnection
Console.WriteLine(FullNameOf<System.Data.IDbConnection>(2));  //System.Data.IDbConnection

Console.WriteLine(FullNameOf<IDbConnection>(-1)); //            IDbConnection
Console.WriteLine(FullNameOf<IDbConnection>(0));  //            IDbConnection
Console.WriteLine(FullNameOf<IDbConnection>());   //            IDbConnection
Console.WriteLine(FullNameOf<IDbConnection>(1));  //       Data.IDbConnection
Console.WriteLine(FullNameOf<IDbConnection>(2));  //System.Data.IDbConnection
Console.WriteLine(FullNameOf<IDbConnection>(3));  //System.Data.IDbConnection

[jnm2]

There are a lot of custom cases mentioned here, some with specialized handling such as wanting part of the namespace relative to another namespace. If infoof/memberof was implemented (#712), then this relatively simple syntax would open the door to folks generating their own specially-customized strings:

MyFormat(infoof(SomeMember))

Similar to how, today, you can already do:

MyFormat(typeof(SomeType))

This doesn't work in constant contexts, but it could be combined with a proposal to allow interceptors to intercept with a constant declaration instead of intercepting with a static method declaration. The compiler could then consider the intercepted expression to be constant. To make this more palatable and have better errors as a language feature, a sigil such as constexpr(...) could be used to require the contained expression to be an method call that is intercepted with a constant.

A downside would be that infoof would require method signatures to be specified if the name specifies a method group with more than one overload.