Getting the overload set of a template

[Alex]

On Monday, 23 April 2018 at 00:26:23 UTC, Simen Kjærås wrote:
>> // tuple("Has foo1_A")
>> pragma(msg, __traits(getAttributes, foo1!"a"));
>> // tuple("Has foo1_A")
>> pragma(msg, __traits(getAttributes, foo2!"a"));
>> // tuple("Has foo1_B")
>> pragma(msg, __traits(getAttributes, foo1!"b"));
>> // tuple("Has foo1_B")
>> pragma(msg, __traits(getAttributes, foo2!"b"));
>
> You explicitly stated 'uninstantiated template'. These are 
> instantiated templates.
>
> This seems to indicate that we're talking past each other. I 
> may have misunderstood what you meant when you wrote "But you 
> won't be able to get the UDA from an uninstantiated template 
> will you?", or one of us has misunderstood some other part of 
> the discussion.

That could be, but we are getting closer :)
So, from the output, we can see, that the both implementation 
cannot be distinguished (at least by the given pragmas)
However, they would be after the new getOverloads version. And 
I'm wondering all the time, if this is wanted, as the new 
getOverloads would imply, that I cannot choose between both 
versions freely.

> There is a limited set of lowerings, and they are defined in 
> the language, not in user code. They include operator 
> overloading (where `a op b` is translated to 
> `a.opBinary!op(b)`), foreach over ranges (where `foreach(e; 
> range) { }` becomes `for (auto e = range.front; !range.empty(); 
> range.popFront()) { }`), string switching (which is forwarded 
> to a template in druntime), and more that I can't recall right 
> now. This is compiler magic meant to make implementating new 
> features and reasoning about existing features, easier. They 
> are briefly described in the article you linked, but I agree it 
> offers limited insight. I've not found any other great sources 
> of information about it, sadly.
>

This is not true, in my opinion.
As an example, Walter gives the rewrite of a while-loop and a 
foreach-loop into a for-loop, stating that by the ability to do 
this, the for-loop is more basic than both of the former.

So, in my mind, every action of rewriting  of something into 
something else is "lowering". And if you can do this (of course, 
maintaining the full semantic equivalence), available actions 
have to remain the same.

Said this, I'm not against the new getOverloads. On the contrary, 
I find the feature cool. But if it is present, it has to yield 
the same results for foo1 and foo2, just like the pragmas.
I'm not sure about the procedure... should I post this as a 
question to the GitHub, so it can be discussed? pull 2351 or 8195?

And yes. I'm lacking information about lowering too. But, if all 
rewrite processes are "lowering" an explicit definition is not 
needed, as "everything" is allowed. It has something natural so 
far...
However, if the PR would be accepted in the form it is now, I 
would make an enhancement request on the docu.