I has been proposed some time ago already and I am still strictly against it. It greatly reduces predictability of compiler invocations which causes problems for larger projects while slightly improving experience of scripters and hobbyists. Not a good trade-off.

It also can't work that way without imposing new restrictions on dub registry as currently it is legal to have same package names in different packages (which is a nice feature to keep).

At the same time convenience gain over simply using dub instead of dmd is almost neglectible.

On Monday, 27 October 2014 at 02:33:18 UTC, Tofu Ninja wrote:
> I don't think this is a new idea but it would be pretty awesome.
>
> So the idea is that the compiler could check dub for libraries that it can't find and automatically download and integrate them. It would essentially make all of dub seem like it was a part of the standard lib and make integrating dub into projects seamless.

[snip]

> Cons:
> Could degrade perceived quality of stdlib if bad dub packages got in.
> Would mean some things could not be compiled without an internet connection.

Cons:

 - Breaks modularity (each thing should do one thing well).
 - Puts pressure on people to use Dub who would prefer not to.
 - Adds complexity to an already highly complex system.
 - Inhibits the development of a "better-than-Dub" alternative.
 - Inhibits the development of alternative compilers.

Regards
Jason

>> Also it is why I suggested that it could be policed.
>
> But the D community is too small for that atm.

which means that it is easy to have a concept of relatively trusted vs unknown contributors.  of course if someone trusted gets hacked or socially engineered then that is a risk, but on the other hand that is true of many other library repositories and there are probably juicier targets.