proposal: private module-level import for faster compilation

[Timothee Cour via Digitalmars-d]

typo:
s/dmd -c -o- -deps A.d/dmd -c -o- -deps B.d

On Wed, Jul 20, 2016 at 12:45 AM, Timothee Cour <thelastmammoth at gmail.com>
wrote:

> currently, top-level imports in a module A are visible by other modules B
> importing A, and are visited (recursively) during compilation of A, slowing
> down compilation and increasing dependencies (eg with separate compilation
> model, a single file change will trigger a lot of recompilations).
>
> I propose a private import [1] to mean an import that's only used inside
> function definitions, not on the outside scope. It behaves exactly as if it
> the import occurred inside each scope (function and template definitions).
> This is applicable for the common use case where an import is only used for
> symbols inside functions, not for types in function signature.
>
> ----
> module A;
> private import util;
> void fun1(){
> // as if we had 'import util;'
> }
>
> void fun2(){
> // as if we had 'import util;'
> }
>
> // ERROR: we need 'import util' to use baz in function declaration
> void fun3(baz a){}
>
> ----
> module util;
> void bar(){}
> struct baz{}
> ----
> module B;
> import A;
> ----
>
> The following should not list 'util' as a dependency of B, since it's a
> 'private import'
> dmd -c -o- -deps A.d
>
>
> The benefits: faster compilation and recompilation (less dependencies).
>
> NOTE [1] on syntax: currently private import just means import, we could
> use a different name if needed, but the particular syntax to use is a
> separate discussion.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20160720/744042f4/attachment.html>