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

[Andrei Alexandrescu via Digitalmars-d]

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