DIP10005: Dependency-Carrying Declarations is now available for community feedback
Joakim via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jan 3 00:10:04 PST 2017
On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu
wrote:
> Regarding the ongoing doubts about the advantages of inline
> imports: they are first and foremost a completion of the nested
> import feature. As such, most, if not all, arguments against
> inline imports apply equally to nested imports. Come to think
> of it, lazy imports vs nested imports:
>
> * same improvement in compilation speed? check
> * no language changes? check
> * no nasty bugs in the aftermath (such as the infamous
> https://issues.dlang.org/show_bug.cgi?id=10378)? check
> * scalable builds? check
>
> Yet local imports are overwhelmingly superior to lazy imports
> because of one thing: they localize dependencies. They
> introduce modularity and its ancillary perks (fast and scalable
> builds, easier review and refactoring) not by engineering, but
> by organically placing dependencies spatially with their
> dependents. (The scope statement does the same thing with
> temporal dependencies.) That the DIP does not make it clear
> that it is a necessary and sufficient extension of local
> imports is a problem with it.
>
> I now am really glad we slipped local imports before the
> formalization of DIPs. The feature could have been easily
> demeaned out of existence.
Except that almost nobody has argued against local imports.
Rather, the argument is that local imports mostly solved this
problem, so why bother adding new syntax for the dozen remaining
symbols from 2-3 modules that are commonly used in template
constraints?
Arguing that local imports have been successful so we should
simply do more of it is not a good argument, as there comes a
point of diminishing returns. You need to show that there are
still worthile gains to be made from changing the language again,
which is why I want to benchmark this feature with Walter before
deciding.
> Allow me to make an appeal regarding the review of any DIP.
> There seems to be a tendency of some reviewers to get attached
> and emotionally invested to their opinion, to the extent they'd
> be hurt by being "wrong" and would go to great lengths to argue
> they're "right". This has obvious negative effects on the
> entire process. Please don't. There's no loss of face to worry
> about. The only commitment we all should have is to the good of
> the D language. If DIP1005 reaches the conclusion of its own
> uselessness, I'd be the first one to write it up and close the
> PR.
We could level this analysis back at you: you consider this DIP
so "obvious" that you are not engaging with our concerns, making
flip, incorrect remarks about how we would have bikeshedded local
imports also.
In the end, this is a minor DIP that is easily bikeshedded, as
everybody can grasp it and have an opinion on it. I have
refrained from commenting recently because I will let
benchmarking settle it for me. Obviously, that won't suffice for
others.
More information about the Digitalmars-d
mailing list