On Thursday, 22 March 2018 at 17:09:55 UTC, Marco Leise wrote:
I understand your opinion and I think it is all reasonable. You
talk about longer compile times since every D module is like a
C++ header. That touches one of my pet peeves with the language
or eco system as it stands and I wonder if you would agree with
me on the following:
Libraries should be tied into applications using interface
files (*.di) that are auto-generated by the compiler for the
_library author_ with inferred function attributes. If after
a code change, a declaration in the *.di file changes, the
library's interface changed and a new minor version must be
released. The language must allow to explicitly declare a
function or method as @gc, impure, etc. so the auto-inferred
attributes don't later become an issue when the implementation
changes from e.g. a pure to an impure one.
Opaque struct pointers as seen in most C APIs should also be
considered for *.di files to reduce the number of imports for
member fields.
That means:
* No more fuzzyness about whether a library function
will remain @nogc, @safe, etc. in the next update.
* Explicit library boundaries that don't recursively import the
world.
I like it but I'd have to think about it a bit more.
My current idea to save me from staring at the screen for 2s at a
time several times a day is to write a program using dmd as a
library and integrate it into reggae that gets all of the
dependencies from a given module. Then the build system reggae
would generate would _not_ declare those dependencies, but
actually .di files generated from them. That way a rebuild would
only happen if the .di file changed, which the program would be
smart enough to not overwrite if the hash/diff hasn't changed.
Atila
