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
