On 12/24/2016 02:16 PM, Joakim wrote:
On Saturday, 24 December 2016 at 17:53:04 UTC, Chris Wright wrote:
On Sat, 24 Dec 2016 09:20:19 +0000, John Colvin wrote:
There are a lot of templates in Phobos that never use the template
keyword. The proposal doesn't only apply to constraints, it applies
to the whole declaration.

If you have a better way of estimating the impact, I'd love to see it.

Can we hold off on the performance discussion?  Walter says this DIP
isn't hard to implement
(https://github.com/dlang/DIPs/pull/51#issuecomment-269077790), so we
will run some numbers and see what we get.  As you know, I too am
skeptical of the benefit but Andrei has shown that import fanout has a
non-negligible cost with his latest benchmark, and actual measurement
will be the best way to decide.

Also (from the cycle "sounding like a broken record") the impact is in other dimension than import speed. From DIP1005:

==========
[...] Dependency-Carrying Declarations have multiple benefits:

* Specifies dependencies at declaration level, not at module level. This allows reasoning about the dependency cost of declarations in separation instead of aggregated at module level.

* If all declarations use Dependency-Carrying style and there is no top-level import, human reviewers and maintainers can immediately tell where each symbol in a given declaration comes from. This is a highly nontrivial exercise without specialized editor support in projects that pull several other modules and packages wholesale. Even a project newcomer could gather an understanding of a declaration without needing to absorb an arbitrary amount of implied context from the declaration at the top of the module.

* Dependency-Carrying Declarations are easier to move around, making for simpler and faster refactorings.

* Dependency-Carrying Declarations allow scalable template libraries. [...]

Dependency-Carrying Declarations also have drawbacks:

* If most declarations in a module need the same imports, then factoring them outside the declarations at top level is simpler and better than repeating them.

* Related, renaming one module is likely to require more edits in a Dependency-Carrying Declarations setup.

* Traditional dependency-tracking tools such as make and other build systems assume file-level dependencies and need special tooling (such as rdmd) in order to work efficiently.

* Dependencies at the top of a module are easier to inspect quickly than dependencies spread through the module.
==========


Andrei

Reply via email to