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

[Dmitry Olshansky via Digitalmars-d]

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