DIP81: Writing files at compile time

[Rikki Cattermole via Digitalmars-d]

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.