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?
