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.
