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

[Chris Wright via Digitalmars-d]

On Fri, 30 Dec 2016 22:42:39 +0000, Stefan Koch wrote:

> On Friday, 30 December 2016 at 22:29:18 UTC, Chris Wright wrote:
>> * Performance improvements, primarily when a module imports another,
>> bulky module for optional functionality.
> That is solved by selective imports.

Well, not today, but it could be. Same with static imports. Both 
accomplish this goal better than DIP1005.

>> * Making it easier to locate where things are defined when reading
>> code.
> 
> That is solved by selective imports.

Static imports do that better than selective imports, though it's more 
typing.

With selective imports, you can either find the declaration in the 
current module, or find the symbol in an import list. If it's imported, 
and the module author is using standard code formatting, you will find 
the import at the top of the module, which will be fast. This is less 
true with arbitrarily scoped imports.

With DIP1005, you rely on there also being selective or static imports. 
If the module author didn't use them, then you have to pull out grep.

>> * Making it easier to move declarations between files.
> 
> That is solved by selective imports.

That helps a bit. You still need to exercise discipline in only using 
selective imports for what you need for visible declarations.

Static imports work about as well, except you can probably write a 
complicated regex replacement to extract out the imports you need.

DIP1005 is a solid improvement here.

Unfortunately, this is a rather marginal usecase.

-- Another thing that just occurred to me: if you're modifying a function 
signature and that brings in another imported symbol, you don't have to 
move to the top of the file or struct to add the necessary import. It's a 
small thing for vim users, who are used to using marks and fast movement 
commands, but if you're using, say, VSCode, that might be painful.