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

[Joakim via Digitalmars-d]

On Thursday, 15 December 2016 at 22:56:42 UTC, Dmitry Olshansky 
wrote:
> On 12/13/16 11:33 PM, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>>
>>
>> Andrei
>
> On first it seems like an awesome idea. That solves ... but 
> wait what? Thinking more  about the problem at hand - I fail to 
> see what this DIP accomplishes that can't be done better today.
>
> 1. The benefit of placing import to each function is based on 
> the untold assumption that we have:
> a) huge modules with many functions
> b) that constraints of these functions require different 
> (large) modules
>
> The reality is far from this picture - if anything 99% of 
> template constraints are dependent on std.range.primitives and 
> std.traits with a bit of std.meta from time to time. So we'd 
> have a boilerplate of
>
> auto foo(R)(R range)
> (import std.range.primitives)
> if(isInputRange!R){ ... }
>
> everywhere for no noticeable benefit - touch one of functions 
> and you get full set of imports of these _small_ modules.
>
> 2. By itself the mechanism for delaying import even for 
> constraint until the function is touched is moot as long as the 
> module in question is huge and is not split in pieces. In other 
> words:
>
> auto foo(R)(R range)
> (import std.range)
> if(isInputRange!R){ ... }
>
> Pulls in full std.range the moment foo is touched, compared to
>
> import std.range.primitives;
> ...
> auto foo(R)(R range)
> if(isInputRange!R){ ... }
>
> which is because it actually isolates the whole mess of 
> complete std.range from the user of a template.
>
> All in all my practical response is split the modules at least 
> in 2 parts: constraints + full functionality, then import the 
> one with constraints at the top level. Works today and solves 
> the practical issues unlike the proposal.
>
> ---
> Dmitry Olshansky

I largely agree with Dmitry. Ilya refactored several Phobos 
modules to use scoped, selective imports much more, and I pitched 
in for some remaining imports in the largest modules, so that 
only these module-level imports remain, ie those necessary for 
symbols imported in template constraints:

std.datetime - https://github.com/dlang/phobos/pull/4373/files
std.uni - https://github.com/dlang/phobos/pull/4365/files
std.string and std.traits - 
https://github.com/dlang/phobos/pull/4370/files

When I first saw this DIP, like Dmitry I was happy that we could 
get rid of those too, but the more I see these horrible syntax 
suggestions for what is really a minor convenience, I changed my 
mind.  std.datetime, the 35k line (17 kloc according to Dscanner) 
beast of phobos, only needs 20 or so symbols at module-scope. 
std.uni- 10k lines, 4.2 kloc- only needs 17 symbols, all from the 
three modules Dmitry mentioned.  I don't think his workaround of 
splitting up modules is even needed for such a low amount of 
module-level imports.

Maybe there are other issues having to do with symbol resolution 
and dependency encapsulation that are addressed by this DIP, ie 
the technical performance of the compiler rather than refactoring 
or code clarity, that I don't fully grasp, but from the first two 
points of the claimed benefits of DCDs, ie ease of reasoning 
about dependencies and refactoring code, I don't think this 
feature will come anywhere close to carrying its own weight.

As for the third benefit having to do with scalable template 
libraries, I'm not sure I completely understand all the details 
there, but I wonder if those problems aren't an artifact of the 
way dmd works now rather than something that can't be fixed 
without this DIP.