On 9/3/2016 2:31 AM, Manu via Digitalmars-d wrote:
Fourth solution:
module myalgorithm;
void test(T)(T t)
{
import std.traits;
mixin("import " ~ std.traits.moduleName!T ~ ";");
mixin("alias M = " ~ std.traits.moduleName!T ~ ";");
// The above could be encapsulated into an eponymous template
// that takes T as a parameter and returns the alias
M.f(t);
}
What makes them problematic or highly unsavory? I thought #4 in particular
was rather cool, I plan to use it as an example.
I also had this idea as workaround, but you can't seriously think this is okay?
Importing an entire module at the point I want to call a function is crazy.
I don't want to import _everything_ from T's module into my local
namespace; that could easily lead to conflicting names in the local
scope which would now require disambiguation.
This surely represents a far higher probability of name collisions
than the theoretical accidental collision that could come from ADL.
The ADL style collision isn't accidental though, that's _the whole point_.
// Find module in which T was defined
template ModuleOf(alias T)
{
import std.traits : moduleName;
mixin("import " ~ moduleName!T ~ ";");
mixin("alias ModuleOf = " ~ moduleName!T ~ ";");
}
The import is scoped inside ModuleOf, and so doesn't cause collisions.
Besides,
import foo : bar;
only imports the symbol 'bar' from 'foo', no matter how many symbols there are
in 'foo'.
Write an algorithm that does _work_, rather than does algorithm logic,
and you can't miss this problem. You need to call associated functions
to do work.
Why does no other language adopt ADL? ADL has been around in C++ for 25 years at
least. Or maybe I missed that it does exist in other languages?
(The usual way I've seen associated functions made available to generic
algorithms is via alias parameters or lambdas that enclose the calls to those
functions.)
