On Thursday, 12 June 2014 at 09:17:45 UTC, Dmitry Olshansky wrote:
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
for production.
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.)
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.
Maybe a change to the compiler to write any mixin'd string out to
a temporary file (along with some identifier information and the
line of code that generated it) and at the next compilation time
try reading it back from that file iff the line of code that
generated it hasnt changed?
Then, there'd be no heavy work for the compiler to do, apart from
read that file in to a string.
