ADL

[Andrei Alexandrescu via Digitalmars-d]

On 9/5/16 11:39 AM, Lodovico Giaretta wrote:
> 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.

ADL would not apply here because it looks up only names in the same 
module as the type.

> 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?

It doesn't sound like a good idea. This kind of lookup that collects 
names from various places and holds an auction is fraught with Byzantine 
failures. Good lookup is regular and predictable.

To implement the range interface for a type, provide a wrapper. KISS. D 
is powerful and that has the danger of making people entitled to ask for 
clever solutions to any problem there is, but at some point it just 
comes down to write some code pulp.


Andrei