On Wednesday, 20 July 2016 at 07:45:12 UTC, Timothee Cour 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).
>

That is purely an implementation problem. SDC doesn't have this problem for instance as it only parse/analyze import on demand.

modules imported by A are already not visible to B, but still required sometime to compile B to resolve A's signatures.

Implementation problem should not be "fixed" by changing the language.

On Wednesday, 20 July 2016 at 18:51:49 UTC, Timothee Cour wrote:
> That means that a change in any single dependency would trigger recompilations in many files.
so what? can you even imagine how many things you'll have to recompile if you'll change something in /usr/include? it's just your tools usually ignoring files there, but here you clearly included all system dependencies, so not ignoring libc system include files is a valid point from my side.

On Wednesday, 20 July 2016 at 19:11:56 UTC, deadalnix wrote:
> Implementation problem should not be "fixed" by changing the language.

this, i believe, closes the topic altogether.

On Wednesday, 20 July 2016 at 19:11:56 UTC, deadalnix wrote:
> Implementation problem should not be "fixed" by changing the language.

I concur. If the root problem is slow compilation, then there are much simpler, non-breaking changes that can be made to fix that.

On Wednesday, 20 July 2016 at 19:59:42 UTC, Jack Stouffer wrote:
> On Wednesday, 20 July 2016 at 19:11:56 UTC, deadalnix wrote:
>> Implementation problem should not be "fixed" by changing the language.
>
> I concur. If the root problem is slow compilation, then there are much simpler, non-breaking changes that can be made to fix that.

Three people agree, this could be a first on the internet!

On Wednesday, 20 July 2016 at 09:35:03 UTC, Dicebot wrote:
> I think this is a wrong approach patching a problem instead of fixing it. Real solution would be to improve and mature .di header generation and usage by compilers so that it can become the default way to import packages/libraries.

As I see dependency resolution has function granularity, but headers have only file granularity. How do you expect headers to work on finer granularity level? If a module depends on another module, the header must assume it depends on all members of that module and if one member indirectly changes due to its private dependencies, it must be assumed that all depending modules must be recompiled, because they depend on the changed module even if they don't depend on the changed member and its private dependencies.

Not sure if tup can solve this problem. It can if it builds full dependency graph for each file instead of having one graph for the whole project.

On Thursday, 21 July 2016 at 08:52:42 UTC, Kagamin wrote:
> Not sure if tup can solve this problem. It can if it builds full dependency graph for each file instead of having one graph for the whole project.

So a solution for make would be -deps reporting full dependency graph per file. Would it work for make?

On 2016-07-21 10:52, Kagamin wrote:

> As I see dependency resolution has function granularity, but headers
> have only file granularity. How do you expect headers to work on finer
> granularity level? If a module depends on another module, the header
> must assume it depends on all members of that module and if one member
> indirectly changes due to its private dependencies, it must be assumed
> that all depending modules must be recompiled, because they depend on
> the changed module even if they don't depend on the changed member and
> its private dependencies.
>
> Not sure if tup can solve this problem. It can if it builds full
> dependency graph for each file instead of having one graph for the whole
> project.

A guess:

module a;

import b;

void foo()
{
    Bar bar;
}

module b;

struct Bar {}

The .di/header for module "a" don't need to include "import b" because "Bar" is not part of the interface of module "a".

-- 
/Jacob Carlborg

On Friday, 22 July 2016 at 06:38:25 UTC, Jacob Carlborg wrote:
> The .di/header for module "a" don't need to include "import b" because "Bar" is not part of the interface of module "a".

It works for your example, but doesn't work for idiomatic D code, which is always heavily templated.

On 07/22/2016 10:23 AM, Kagamin wrote:
> On Friday, 22 July 2016 at 06:38:25 UTC, Jacob Carlborg wrote:
>> The .di/header for module "a" don't need to include "import b" because "Bar" is not part of the interface of module "a".
> 
> It works for your example, but doesn't work for idiomatic D code, which is always heavily templated.

.. which naturally leads to watching about Benjamin DConf talk about fixing "export" and that is where everything clicks together. Organizing large projects as bunch of small static libraries per package and defining public API of those via `export` (and not just public) would achieve this topic goal and much more, all without changing the language.