listing template function overloads for use in compile time decisions

[Atash via Digitalmars-d]

Let's say that we have a struct `A` that contains some template 
function named `fn` template-parameterized on its argument types:

struct A {
...
void fn(A)(auto ref A a) { ... }
...
}

I cannot get a handle on `fn` as an alias when searching for 
overloads of the string "fn" in `A` via 
`__traits(getOverloads,A,"fn")`. This makes sense, obviously, 
because `fn` doesn't really 'exist' as a template.

But the compiler can, nevertheless, generate a proper 
implementation of `fn` depending on its argument(s). It doesn't 
have to create the code, as with e.g. `__traits(compiles, 
A.init.fn(0))`. While it doesn't make sense to list overloads of 
a given name when they're templates, it does make sense that 
given some argument types and qualifiers all candidate functions 
can be easily enumerated. I can't find such a feature, however.

Moreover, I cannot figure out how one could acquire a handle on 
even *just* the best match for a given function name with some 
given argument types.

With this, library writers could perform their own overload 
resolution without enforcing the use of wrapper classes when 
trying to plug one library into another library, ex. lib A has 
struct A with `fn` and lib B has struct B with `fn` and they have 
functions `fn` that accept each other and we want to choose the 
one that partially specializes on the other over the one that 
doesn't. It's basically the decision process behind the rewriting 
that occurs with a.opCmp(b) vs. b.opCmp(a), but fully emulated in 
the presence of templates without extra client-code-side hints 
and taking into account granularity finer than the four levels of 
overload resolution. It moves glue-code (or glue-behavior like 
argument ordering to a library function) from the user to the 
library writer, and allows that glue-code to be generic.

Is this a facility that is present in D, and I missed it? Are any 
of the above bulleted use-cases manageable with present-day D?

I'm kind of an obsessive metaprogramming-fiend, so this little 
issue is strangely vexing. I've come up with an idea for a 
solution, and am attempting to implement it, but it's 
extraordinarily hackish. It assumes that the name `fn` when 
called can be entirely resolved with its arguments by looking at 
the arguments' types and their template parameters (if any) and 
implicit target conversions (and their template parameters [if 
any]). I'm seeing in my head a combinatoric blow-up from the 
possible orderings of template arguments in the template 
declaration of `fn`, so... yeah. Kinda would like a __traits 
thing that gets all possible resolutions of a symbol in a call 
expression.

Thanks for your time~!