12-Jun-2014 03:29, Adam D. Ruppe пишет:
On Wednesday, 11 June 2014 at 18:03:06 UTC, Atila Neves wrote:
I wish I'd taken the mic at the end, and 2 days later Adam D. Ruppe
said what I was thinking of saying: unit test and debug the CTFE
function at runtime and then use it at compile-time when it's ready
Aye. It wasn't long ago that this wasn't really possible because of how
incomplete and buggy CTFE was, you kinda had to do it with special code,
but now so much of the language works, there's a good chance if it works
at runtime it will work at compile time too.
I was really surprised with CTFE a few months ago when I tried to use my
dom.d with it... and it actually worked. That's amazing to me.
But anyway, in general, the ctfe mixin stuff could be replaced with an
external code generator, so yeah that's the way I write them now - as a
code generator standalone thing then go back and enum it to actually
use. (BTW I also like to generate fairly pretty code, e.g. indentend
properly, just because it makes it easier to read.)
This one thing I'm loosing sleep over - what precisely is so good in
CTFE code generation in _practical_ context (DSL that is quite stable,
not just tiny helpers)?
By the end of day it's just about having to write a trivial line in your
favorite build system (NOT make) vs having to wait for a couple of
minutes each build hoping the compiler won't hit your system's memory
And these couple of minutes are more like 30 minutes at a times. Worse
yet unlike proper build system it doesn't keep track of actual changes
(same regex patterns get recompiled over and over), at this point
seamless integration into the language starts felling like a joke.
And speaking of seamless integration: just generate a symbol name out of
pattern at CTFE to link to later, at least this much can be done
relatively fast. And voila even the clunky run-time generation is not
half-bad at integration.
Unless things improve dramatically CTFE code generation + mixin is just
our funny painful toy.