The future of UDAs.

[Artur Skawina]

On 11/27/12 19:56, Gor Gyolchanyan wrote:
> The problem is that it's impossible to perform compile-time actions on a combination of modules in different compiler runs. different directly unrelated modules could contribute to the code generation process if mutable compile-time variables were available.

No.

Unless you want to effectively use a two-stage build process - at which point
it no longer really is "CTFE". IOW, what you're asking for is basically semi-
persistent backing store for compile-time objects. When you /really/ need that
kind of functionality, splitting out the "code generator" is fine.
D's design allows for much smarter compilers than the ones currently available,
the way module dependencies work is essential for that.

What you seem to want to do can be done, as already explained in this thread,
at runtime, or as an additional custom build stage (mark the required types/
objects using UDA's (or otherwise), compile the project, run your custom tool
that scans for the markers and generates code, compile that and then link it all
together). There really is no alternative, other than automating this by 
introducing new "special" kind of modules, that are built during the final link
phase. (Well, theoretically you could also invent ugly hacks where just some ops
on certain magic data types work, but...).

artur