On 12/15/2016 09:31 AM, Meta wrote:
On Thursday, 15 December 2016 at 13:49:26 UTC, Andrei Alexandrescu wrote:
On 12/14/2016 10:26 PM, Meta wrote:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Andrei
What's the main goal with this proposal?
If the document does not clarify that, please let me know of
specifics. Thanks. -- Andrei
Well of course it is about DCDs, but I am talking more about the
underlying motivation. The listed benefits of DCDs from the DIP:
1. 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.
2. Dependency-Carrying Declarations are easier to move around, making
for simpler and faster refactorings.
3. Dependency-Carrying Declarations allow scalable template libraries...
Distributing a template library in the form of Dependency-Carrying
Declarations creates a scalable, pay-as-you-go setup.
It seems to me that making all imports lazy accomplishes 3, which is the
real prize. 1 and 2 are nice to have, but it doesn't seem to me that the
added complexity of the inline import feature is worth it when the
biggest bang for our buck is not 1 or 2, but 3.
So my question is, what do you want? Is your primary goal to introduce
DCDs into the language to allow for easier refactoring and having it
made more clear which imports a declaration uses, or is it to make
imports "pay as you go" such that a user only pays for what they
actually use and it's more or less transparent to them? You argue in the
DIP that DCDs give us all 3 so we don't have to choose, but as I said
previously, DCDs will not give us the biggest ROI compared to the cost
of the feature.
Thanks for sharing your opinion. Mine (and the argument made by DIP1005)
is that on balance packing dependencies together with declarations is
worth the language addition. The document does specify the advantages
and disadvantages of lazy imports, as follows:
===
* Full lazy `import`s. Assume all `import`s are lazy without any change
in the language. That would allow an idiom by which libraries use fully
qualified names everywhere, and the `import`s would be effected only
when names are looked up. This would allow scalability but not the
dependency-carrying aspect.
===
If that is misrepresenting things, please let me know so I can improve
the DIP.
Andrei
