Little self-promotion here, and in case Walter misses some of them:
http://d.puremagic.com/issues/show_bug.cgi?id=2744
http://d.puremagic.com/issues/show_bug.cgi?id=2745
http://d.puremagic.com/issues/show_bug.cgi?id=2747
http://d.puremagic.com/issues/show_bug.cgi?id=2748
http://d.puremagic.com/issues/show_bug.cgi?id=2751
If it's about bugs, it would (probably) be easier for Walter to fix that
code generation bug, that forces dsss/rebuild to invoke a new dmd
process to recompile each outdated file separately.
This would bring a critical speedup for incremental compilation (from
absolutely useless to relatively useful), and all impatient D users with
middle sized source bases could be happy.
In c++, a sophisticated makefile carefully build .h dependencies of .c
files. Thus, once .h files are updated, then .c files which are based on
them need to be recompile. This detection can be made by comparison of
old .di files and new .di files by testing their equality.
This sounds like a really nice idea, but it's also quite complex.
For example, to guarantee correctness, the D compiler _always_ had to
read the .di file when importing a module (and not the .d file
directly). If it doesn't do that, it could "accidentally" use
information that isn't included in the .di file (like code when doing
inlining). This means you had to generate the .di files first. When
doing this, you also had to deal with circular dependencies, which will
bring extra headaches. And of course, you need to fix all those .di
generation bugs. It's actually a bit scary that the compiler not only
has to be able to parse D code, but also to output D source code again.
And .di files are not even standardized.
It's perhaps messy enough to deem it unrealistic. Still, nice idea.
