Let's say I have a function template:

template foo(T)
{
   void foo(T t) {}
}

I want to get the overloads of foo based on the instantiation foo!int, let's say.

But __traits(getOverloads, foo!int, "foo") doesn't work. Instead, it thinks I want:

__traits(getOverloads, foo!int(), "foo")

If I change the function name to not be eponymous, it works:

template foo(T)
{
   void bar(T t) {}
}

__traits(getOverloads, foo!int, "bar") // ok!

Is there a trick to disable the property rewrite? I tried alias, no dice.

-Steve

On 1/23/21 1:00 PM, Steven Schveighoffer wrote:
> Let's say I have a function template:
> 
> template foo(T)
> {
>     void foo(T t) {}
> }
> 
> I want to get the overloads of foo based on the instantiation foo!int, let's say.
> 
> But __traits(getOverloads, foo!int, "foo") doesn't work. Instead, it thinks I want:
> 
> __traits(getOverloads, foo!int(), "foo")
> 
> If I change the function name to not be eponymous, it works:
> 
> template foo(T)
> {
>     void bar(T t) {}
> }
> 
> __traits(getOverloads, foo!int, "bar") // ok!
> 
> Is there a trick to disable the property rewrite? I tried alias, no dice.
> 

As pointed out by Adam Ruppe, this isn't what I thought it was.

foo!int is really an alias to foo!int.foo. So the __traits(getOverloads) call is working as expected.

But maybe this calls into question the mechanism of getOverloads. If I have a symbol that is an overload set, why should I have to jump through hoops to find its parent and then convert it to a string?

Wouldn't it be better with something like:

__traits(overloadsFor, symbol)

and then you just do

__traits(overloadsFor, __traits(getMember, aggregate, "symbolname"))

if what you have is an aggregate and the member name?

-Steve