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

[John Colvin 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

+1

I understand the motivation for the proposal but I think that 
good practice with package/module organisation renders the 
benefits marginal. The flipside of that is that introducing this 
new syntax reduces the pressure on people to organise their code 
sensibly.

Is it a feature I'd like to be able to use when I'm writing: yes

Is it a feature I actually want to see in D and in the D 
codebases I read daily: probably no, meh

Is it worth the time and effort of core developers and community 
reviewers, both now and as an ongoing feature-maintenance burden: 
absolutely not. I have no idea why this proposal is a priority 
right now.