DIP10005: Dependency-Carrying Declarations is now available for community feedback
Dmitry Olshansky via Digitalmars-d
digitalmars-d at puremagic.com
Thu Dec 15 14:56:42 PST 2016
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
More information about the Digitalmars-d
mailing list