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

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Fri Dec 30 17:56:54 PST 2016


On 12/30/16 7:32 PM, Chris Wright wrote:
> 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.

Is this fact or opinion? If the former, could you please point where 
DIP1005 is getting it wrong. Thanks.

>>> * 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.

So whether that's overall better is not settled, is it? We can't really 
define "better" as whatever each participant believes.

> 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.

DIP1005 allows the declaration to encapsulate its own dependencies. Of 
course if top-level imports are also present, the benefit erodes.

>>> * 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.

That's one of the many benefits of encapsulation.


Andrei




More information about the Digitalmars-d mailing list