ADL

[Lodovico Giaretta via Digitalmars-d]

On Monday, 5 September 2016 at 08:17:15 UTC, Andrei Alexandrescu 
wrote:
> Are we in agreement about the baseline solution?

Yes, but there are a bunch of cases in which the baseline 
solution is not applicable.

Disclaimer: I don't know how C++ would handle the following 
situation.

Let's say I use a library that exposes a type T. Of course the 
library does not expose a range interface for it. So I create a 
module t_range, which provides free range functions for type T. 
This is akin to what Phobos does for arrays, whose range 
functions are in std.array.

Now I want to use std.algorithm on T, as I would use it on 
arrays. But I can't, because the only reason std.algorithm works 
on arrays is because it imports std.array. But of course it 
cannot import my module t_range.

What I'd like as a solution is that the template does not only 
look in its module, but also in the instantiating module, to 
resolve symbols dependent on the template types. So std.algorithm 
should not import std.array, but should work on arrays if the 
instantiating module imports std.array, and should work on T if 
the instantiating module imports t_range, which is a sound 
behaviour that would not surprise anyone.

Incidentally, this would also solve the problem of emplacing 
objects with private or package constructors and probably also 
some of the current discussions about visibility of private 
members in templates (private members would be visible only if 
they are visible at the instantiation site)

So templates would work as if they were mixed-in the 
instantiating module, and they would work as if the user 
explicitly wrote that piece of code specialized for its case 
directly in the usage site (which is what templates are for: 
avoiding to write every possible specialization).

I know this is a big breaking change that will probably never 
happen, but I think it would be an interesting scenario and would 
open lots of possibilities. What do you think?