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