DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Chris Wright via Digitalmars-d]

I'm looking at this part:

> The manual conversion of std.array to the "static import" form is shown
> here. It leads to the expected lengthening of the symbols used in
> declarations, which appears to eliminate one disadvantage by
> introducing another.

You get longer declarations when you're reading and writing code. This 
shouldn't impact the docs. Not arguing that there is a disadvantage, just 
pointing out the scope is relatively small.

All your references are entirely unambiguous. If I'm reading the source 
and I'm unfamiliar with phobos, I don't have to wonder if that template 
constraint comes from std.string or std.traits.

It's two benefits for one disadvantage.

You can also have renamed imports to reduce the amount of typing:

  static import trait = std.traits;
  trait.ForeachType!Range[] array(Range)(Range r)
  if (trait.isIterable!Range &&
      trait.isNarrowString!Range &&
      !trait.isInfinite!Range)) {
  }

> The manual conversion of std.array to the "selective import" form is 
> shown here. Conversion was successful but because it collapses all 
> imports at the top, it does not make it much easier to identify e.g. 
> what dependencies would be pulled if a given artifact in std.array were 
> used.

It's still trivial for the compiler to detect which modules a particular 
declaration depends on.

If I'm in vim, I can put my cursor on the declaration, hit '*', navigate 
to the top of the document, and find the next match. It's like five 
keypresses. With VS Code or the like, I can similarly go to the top of 
the file and find the first match without much trouble.

And this process tells me which module defines the symbol. Either the 
first hit is at the top of the file in the import section, and I know 
which file to look in, or it's not, and I know it's defined locally (and 
there's a good chance I'm at the declaration).

With your proposal, when I'm lucky, I know the declaration must be either 
in the current file or in the locally imported file. (When I'm unlucky, 
the file has some top-level imports or multiple local imports.) And since 
the utility of this is mostly for large modules, I'm still going to pull 
out grep. It *does* help when I need to import the same thing elsewhere, 
at least.

> Again the manual process was highly nontrivial.

This is also true for your proposal.

CyberShadow also offered to whip up a tool to automate the conversion to 
selective imports. Presumably they would be able to do something similar 
with your proposal.

So this is kind of irrelevant.