proposal: private module-level import for faster compilation

[Sebastien Alaiwan via Digitalmars-d]

On Wednesday, 20 July 2016 at 19:59:42 UTC, Jack Stouffer wrote:
> I concur. If the root problem is slow compilation, then there 
> are much simpler, non-breaking changes that can be made to fix 
> that.

I don't think compilation time is a problem, actually. It more 
has to do with dependency management and encapsulation.

Speeding up compilation should never be considered as an 
acceptable solution here, as it's not scalable: it just pushes 
the problem away, until your project size increases enough.

Here's my understanding of the problem:

// client.d
import server;
void f()
{
   Data x;
   // Data.sizeof depends on something in server_private.
   x.something = 3; // offset to 'something' depends on 
privateStuff.sizeof.
}

// server.d
private import server_private;
struct Data
{
   Opaque someOtherThing;
   int something;
}

// server_private.d
struct Opaque
{
   byte[43] privateStuff;
}

I you're doing separate compilation, your dependency graph has to 
express that "client.o" depends on "client.d", "server.d", but 
also "server_private.d".

GDC "-fdeps" option properly lists all transitive imported files 
(disclaimer: this was my pull request). It's irrelevant here that 
imports might be private or public, the dependency is still here.

In other words, changes to "server_private.d" must alway trigger 
recompilation of "client.d".

I believe the solution proposed by the OP doesn't work, because 
of voldemort types. It's always possible to return a struct whose 
size depends on something deeply private.

// client.d
import server;
void f()
{
   auto x = getData();
   // Data.sizeof depends on something in server_private.
   x.something = 3; // offset to 'something' depends on 
privateStuff.sizeof.
}

// server.d
auto getData()
{
   private import server_private;

   struct Data
   {
     Opaque someOtherThing;
     int something;
   }

   Data x;
   return x;
}

// server_private.d
struct Opaque
{
   byte[43] privateStuff;
}

My conclusion is that maybe there's no problem in the language, 
nor in the dependency generation, nor in the compiler 
implementation.
Maybe it's just a design issue.