On 13/08/2015 6:37 a.m., JDemler wrote:
Triggered by the original forum thread I wrote a DIP to further explain
the idea of the writing files at compile time feature and its implications.
http://wiki.dlang.org/DIP81
Please discuss!
Problem:
debugging
The debugger cannot attach to mixedin code; one has to print the
resulting code with pragma(msg, ) to inspect it
Fix:
Make D interface file generation include the source code e.g.
statements.
Pros:
- Already have most of the code to do this
Cons:
- None.
Problem:
compile-speed
Even if the resulting code does not change, mixedin code has to be
compiled anyway
True. Why is this a problem exactly?
Problem:
scalability
If the generated code is needed in two seperated places of the code,
it has to be mixedin twice or has to be mixedin into a special module
which introduces overhead
Not a problem? The result should *theoretically* the return value should
be cached. We could even go so far as to have ``mixin(string)`` as the
return type. To cache the AST and force compile time only. Perhaps even
make it return the assembly code itself for runtime?
Problem:
transparency
As user of a library which relys on compile time code generation one has
often no idea what code is generated
See debugging problem for the solution.
We do not need to add a new language feature based upon these problems
and use cases. We can solve it by simply extending one we already have.
D interface files. Making them generate the full source code instead of
just the interface.
