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