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

Meta via Digitalmars-d digitalmars-d at puremagic.com
Thu Dec 15 06:31:57 PST 2016


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.


More information about the Digitalmars-d mailing list