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

Adam D. Ruppe via Digitalmars-d digitalmars-d at puremagic.com
Sat Dec 31 07:05:00 PST 2016


On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu 
wrote:
> Destroy.
>
> https://github.com/dlang/DIPs/pull/51/files

FYI, from the DIP, this is false:

"The static import setup does not share the issue above, at the 
cost of being cumbersome to use---all imported symbols must use 
full lookup everywhere. A reasonable engineering approach would 
be to define shorter names:"

It then proceeds to list a bunch of local aliases. That's not how 
I'd do it because you can also simply use a renamed import:

static import r = std.range.primitives;

void foo(R)(R range) if(r.isInputRange!(range)) // works today


If the import were lazy - which there's no reason not to be with 
a static import, renamed or not, since its use is always explicit 
- then this gives most the same advantages of the DIP.

Granted, you'd still have to look up what `r` means, so it isn't 
100% dependency carrying.



Another current language option not discussed in the document is 
an eponymous template.


But there is another language option today: an eponymous template.

Consider the following:

with (import std.stdio) void process(File input) ;

Let's rewrite that to be:

template process() {
    import std.stdio;
    void process(File input) {

    }
}


The whole symbol is now lazy and encapsulated... and thanks to 
the existing eponymous rules, it'd be semi-transparent to the 
user (just error messages would be the main source of leakage, oh 
god the error messages could be so ugly).

But it works in today's D.



BTW it is my opinion that the "one file, one module" rule is a 
mistake. Even with all these things, the declarations are still 
not *guaranteed* to carry their dependencies, since top-level 
imports still leak in. Separate modules don't have that problem, 
and if we could just define several modules in one file, we'd 
basically destroy this DIP in one swift stroke.

I doubt y'all would change that, but still, I'd list that as an 
alternative in the section that lists many small files as being a 
major disadvantage, since while we are discussing changing the 
language, that's a possible change too unless explicitly off the 
table.


More information about the Digitalmars-d mailing list