https://issues.dlang.org/show_bug.cgi?id=13855
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #8 from [email protected] --- In light of the recent move towards local imports vs. global imports, I'm starting to think that what we *really* want is for the compiler to *automate* imports for us. It's analogous to the old days with (early versions of) C, where you have to declare all local variables at the top of the function. C++ improved on this by allowing variable declarations closer to where they're actually used (I'm not sure if this is standard C, but recent implementations like gcc seem to have also adopted this in C code). This is like moving imports from module scope to local scope. However, C++ (well, earlier versions of it) still suffered from having to type incredibly long type names, like: ------ std::vector<int>::iterator it = std::vector<int>::iterator::end; ------ D improved upon this by allowing the LHS type name to be elided where the type can be inferred by the compiler. Most of the time, this is possible, so in modern idiomatic D code these days, using `auto x = ...` is commonplace and greatly improves legibility. What if we had an analogous "import inference", where you don't need to spell out long complicated module names just to be able to use some symbol in some module std.abc.xyz? Let the compiler figure it out for us. This is still a raw initial idea, so it will need further refinement, but my thought is something along these lines: suppose we introduced a "lazy import" construct: ------ auto myFunc(Args...)(Args args) { lazy import std.algorithm; return args.map!(x => x*2).filter!(x < 100); } ------ The lazy import tells the compiler that if undefined symbols are encountered, it should look into std.algorithm to see if the symbol is defined there. If it is, implicitly import the module that it's defined in, and keep going. Otherwise emit an error message. If there is any ambiguity that arises, e.g., both std.algorithm.foo.bar and std.algorithm.baz.bar exist, and `bar` is referred to, then also emit an error, and require disambiguation using the usual mechanisms (e.g., naming `foo.bar` or `baz.bar`). If a recent proposal for `import std;` gets accepted, then we could even have: ------ lazy import std; // I'm lazy, just lookup all symbols in Phobos for me ... // use std.*.* to your heart's content ------ This could be placed either in module scope or in local scope, depending on just how lazy you are. It kills all boilerplate and verbosity by reducing import statements to their bare minimum. --
