Some more details on my proposa based on UDA:

// applies to next decl
@deps!({import std.algorithm;})
void test1(){}

// applies to a set of decls
@deps!({import std.stdio;}){
  void test2(){}
  void test3(){}
}

// applies to all following decls (':')
@deps!({import std.array;}):

// can specify other dependencies beyond imports and have arbitrary complex logic:
@deps!({
  import std.range;
  static int[100] data2;
  version(linux){
    enum data1=import("foo");//string import
    pragma(lib, "curl");
  }
}):
void test4(){}

// Can alias some dependencies:
alias deps1=deps!({import std.algorithm;});

@deps1
void test4(){}

NOTE: the above code compiles if we add
`struct deps(T...){}`, but that logic would be implemented in the compiler.

Advantages:

* no new syntax (just new semantics)
* no nesting inside {} required, so no additional indentation
* allows grouping multiple declarations under a single set of imports
* `grep import` will still work unlike many of the existing proposals
* can use existing traits to query for such imports (eg getSymbolsByUDA) 
* allows a more general solution (eg also handles `pragma(lib, "curl");` if we want that as well)

(Note: ignore the `variant 2` i had described above)

On Thu, Dec 15, 2016 at 8:32 AM, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On 12/15/2016 11:11 AM, Walter Bright wrote:
On 12/15/2016 6:53 AM, Andrei Alexandrescu wrote:
The document does specify the advantages and disadvantages of lazy
imports, as follows:

===
* Full lazy `import`s. Assume all `import`s are lazy without any
change in the
language. That would allow an idiom by which libraries use fully
qualified names
everywhere, and the `import`s would be effected only when names are
looked up.
This would allow scalability but not the dependency-carrying aspect.
===

That would be a massive breaking change.

This may be a misunderstanding. The idiom would be opt-in so existing behavior will be preserved (albeit it won't benefit of the improvements).

Andrei