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

[deadalnix via Digitalmars-d]

There are quite a few fallacies in there.

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.
>

There is a major difference with this DIP.

Lazy import is not a language change, but a compiler 
implementation detail. As such, it doesn't require a DIP or 
anything specific.

Nested import are a language simplification. Declaration can 
appear anywhere, import is a declaration, the fact that import 
couldn't appear anywhere was an arbitrary limitation, and 
removing it makes the language simpler. As such, the burden of 
proof is on maintaining the limitation rather than removing it.

This DIP is a language addition. Therefore, contrary to nested or 
lazy import, the burden of proof is on it. This DIP should be 
considered as follow: how much complexity does it add and how 
much benefit does it bring, compared to alternatives.

The obvious benefit is localizing dependencies. I think I'm not 
too far off track by considering most of the speedup and scalable 
build can be achieved with lazy import and, while I'm sure there 
are example where this is superior, we are talking marginal gains 
as lazy and nested imports squeezed most of the juice already.

The cost is the language addition. The first obvious improvement 
that can be made to this DIP to reduce its cost is to not 
introduce a new syntax. As such, the addition is limited to 
allowing the existing syntax in a new place rather than adding a 
whole new syntax for imports.

I like the extra expressivity. I'm not 100% convinced it is worth 
the extra cost, but the more the cost is reduced, the more 
rational it seems to me that this option should be pursued.

> I now am really glad we slipped local imports before the 
> formalization of DIPs. The feature could have been easily 
> demeaned out of existence.
>

Good you also notice how broken the DIP process is.

One suggestion: let's keep the DIP describing the change to be 
made. Some examples are fine to illustrate, but it is not the 
DIp's purpose to be easy to understand or expand too much in 
argumentation, or it'll be useless as a spec document, and trying 
to have the DIP be a spec, a tutorial, a essay on why the 
feature, and so on just lead to endless rewriting lead to 
perpetual motion but no progress.