On Wednesday, 9 August 2017 at 23:57:19 UTC, Johnson Jones wrote:
Sometimes one doesn't want to import either the whole module nor specify a single function to import.

There was a proposal called "dependency carrying declarations" about that, but a library trick was found to beat it:


They called it "self-important lookups"...though the PR was never actually merged, but as you can see in there, the code was actually quite trivial (the PR is about 95% documentation):

template from(string moduleName)
    mixin("import from = " ~ moduleName ~ ";");

So then you can do an inline import and reference right there.

It seems that basically D has all the info to import the function implicitly because it usually gives a nice error message tells us which module to import for the function.

It is guessing there, giving a hint to users but it doesn't actually have enough information to fix it automatically. Consider:

struct A {
  static struct B {
      static void C() {}

in that case A.B.C() is the struct function, not an import. The line between the package+module and the inner symbol is unknown without an import.

Sometimes we still need to specify the fully qualified name due to conflicts with other modules.

Keep in mind too that you can do renamed imports:

import short = some.long.name;

short.foo(); // refers to some.long.name.foo();

Rather, how about a new feature were we do not have to import modules at all by specifying the fully qualified name? Since conflicts might occur, how bout using a symbol to express that?


This is what the `from!"A.B".C()` trick linked above enables. But notice that the module is in quotes - it still doesn't know where where the line is drawn between module and inner name without you telling it somehow.

Reply via email to