• Steven Schveighoffer (18/18) Jan 23 2021 Let's say I have a function template:
• Steven Schveighoffer (13/39) Jan 23 2021 As pointed out by Adam Ruppe, this isn't what I thought it was.

Steven Schveighoffer <schveiguy gmail.com> writes:

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

Steven Schveighoffer <schveiguy gmail.com> writes:

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