ADL

[deadalnix via Digitalmars-d]

On Monday, 5 September 2016 at 13:35:02 UTC, Andrei Alexandrescu 
wrote:
> On 9/5/16 11:43 AM, Timon Gehr wrote:
>> On 05.09.2016 06:05, Manu via Digitalmars-d wrote:
>>> An algorithm that calls a function on
>>> some T it receives just wants to look near the T; UFCS 
>>> functions will
>>> be there.
>>
>> I agree with your post except for this.
>>
>> In general there could be four modules: one defines the type, 
>> one
>> defines the UFCS function, one defines the generic algorithm, 
>> and the
>> last one imports the former three. The problem is that D has 
>> no standard
>> way to make them work together.
>
> Do you think there should? And if so, what would the algorithm 
> be? -- Andrei

I ran into that very problem many time, and I think it is 
legitimate.

Typical use case is a type from module A that is extended by 
module B to conform to whatever typeclass is desired (a range for 
instance) via UFCS. It is not possible to pass it down to 
anything generic expecting that typeclass is not passed down.

However, it is not clear what the solution should be. Tweaking 
the identifier resolution would make template instance dependent 
on the instantiation point, which is a non starter (it would 
cause an explosion is both resources required to compile and a 
huge amount a binary bloat).

On the other hand, I was wondering if it is possible to create a 
wrapper type type, with alias this, that is dependent on the 
scope, and that do UFCS resolution is that scope. One could then 
use the template like :

myalgorithm(forwardUFCS(var));

With var the vairable of the type extended to fit the typeclass. 
I suspect this can be done with a fair amount of mixin magic, but 
I'm not 100% sure.

This way, forwarding the instancier scope would only be done on 
demand, which would mitigate the instanciation explosion problem 
one face when doing it as identifier resolution level.