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

[Dominikus Dittes Scherkl via Digitalmars-d]

On Tuesday, 3 January 2017 at 12:57:22 UTC, Andrei Alexandrescu 
wrote:
> On 01/03/2017 02:19 AM, Dominikus Dittes Scherkl wrote:
>> On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu 
>> wrote:
>>> DIP1005 gives consideration to the speed of compilation 
>>> aspect in
>>> larger proportion than speed's importance; the first and 
>>> foremost
>>> benefit of DIP1005 is it closes the gap on dependency 
>>> encapsulation,
>>> which had been very successfully narrowed by local imports.
>> I love that idea. But I still can't see why this requires any 
>> new
>> syntax. Simply extending the scope of local inports to include 
>> the
>> function header is enough.
>
> I'll mention this possibility in the DIP.
Good.
>
>> Only for .di-generation it may be useful to move all local 
>> imports to
>> the declaration (maybe with this new syntax "with" before it) 
>> - but that
>> should be done with ALL local imports, because today the 
>> .di-files are
>> incomplete and will stay so if the new syntax is introduced but
>> "old-style" local imports still valid and not exported to the 
>> .di.
>> Or the old local imports become deprecated together with the
>> introduction of the new "with" syntax and vanish soon after 
>> that.
>
> Local imports don't pertain to the interface, they are an 
> implementation detail. Why would those be made a part of the 
> .di?
.di are needed to ship with a library. If a function locally 
imports some type, the library is dependant on that import, so if 
I want to use the library, I have to install all stuff it depends 
on too. And to find out, what exactly the library depends on the 
.di is the place I look, so there need to be mentioned each and 
every import - no matter how deeply local that may be. If that is 
not the case it renders .di-files completely useless to me (as 
they are at the moment), because I need to find out the 
dependencies somewhere else (e.g. in some documentation of the 
library).
While it is likely that the dependencies of a library may be 
documented somewhere, this is not guaranteed. But .di-files are 
guaranteed to ship with a lib because else it cannot link - at 
least if it contains any templates, which is about 100% sure for 
a language like D. So I would like to see local imports in the 
.di-file, even if they are not strictly needed to compile because 
the imported types are not exposed in the function signature.