proposal: lazy compilation model for compiling binaries

[Andrei Alexandrescu]

On 6/24/13 1:52 AM, OlliP wrote:
> This is now a bit confusing to me. I just made up my mind to go
> with D instead of Go, because Go is too simplistic in my opinion.
> Furthermore, calling C from D is a lot easier than from Go. And
> now this ... I have too little understanding of D to see what the
> impact of this build time issue is. Does this mean build times
> come close to what they are in C++ or is this issue only about
> builds not being as fast as the D people are used to ..?
>
> Thanks, Oliver

This forum is concerned with improving D and discussing its subtler 
aspects. When a point is being argued, pedaling up or down certain 
points is a common practice in attempting to make an argument stronger. 
For example, "Currently, D suffers from a high degree of interdependency 
between modules" could be more accurately (and boringly) be described as 
"Currently, D's standard library is coarse-grained and favors internal 
reuse over internal decomposition".

Such issues (and exaggerations thereof) are commonly found in this 
newsgroup, for the simple reason this is the place to be for discussing 
them.

This particular one is not stringent for our users, but it did come up 
in internal testing (which instantiates all templates in large modules 
such as std.algorithm). We have just implemented a proposal that allows 
migrating from coarse-grained to fine-grained modularity in a library 
(notably the standard library itself) without disrupting its clients.


Andrei