On 12/20/13 9:38 AM, H. S. Teoh wrote:
Hmm. Why do we need to incorporate the 'import' keyword in the first
place?
To make the intent explicit. But that's an interesting idea. I'd
probably require a leading '.' just to make it unambiguous that lookup
must start from top level.
What about extending symbol lookup, so that if a fully-qualified
symbol x.y.z can't be found in the current symbol tables, and x/y exists
in the current import path, then implicitly try to import x.y and lookup
z in that module. Then you could just write:
void f(T)(T t) if (std.range.isInputRange!T) ...
Due to a bug that's actually the case today to some extent :o).
Andrei
