newCTFE Status August 2019

[Jonathan M Davis]

On Saturday, August 31, 2019 4:00:47 PM MDT Jon Degenhardt via Digitalmars-d 
wrote:
> On Saturday, 31 August 2019 at 21:49:18 UTC, Adam D. Ruppe wrote:
> > On Saturday, 31 August 2019 at 21:44:38 UTC, Jon Degenhardt
> >
> > wrote:
> >> By coincidence, I just ran into a case. I'm curious, will
> >> newCTFE enable the usage below?
> >
> > This isn't actually a CTFE engine thing, just the library
> > implementation.
>
> Interesting. Thanks Adam. Suggests that there's more to having
> consistent behavior than just the engine itself.

Well, the second example didn't even use CTFE. CTFE gets used when the
result needs to be known at compile time. The init value of a struct needs
to be known at compile time, so anything that directly initializes a
struct's members has to be known at compile time and will trigger CTFE. On
the other hand, a non-static, local variable doesn't need to have its value
known at compile time, so CTFE isn't used.

The only question of consistent behavior here is whether the expression
being evaluated can be done at both compile time and at runtime, and due to
how to!string uses a C function to format floating point values, it only
works at runtime. The same will happen any time that a piece of code calls a
C function or does anything else that can't be done at compile time. That's
why some code uses

if(__ctfe)

to provide an alternate implementation that works at compile time (e.g. if
pointer arithmetic were being used for performance in the non-CTFE branch of
the code). However, in this case, rather than having a small change to the
code for a CTFE branch, having a CTFE branch of the code would require
providing an implementation for formatting floating point values which was
entirely written in D - which IIRC Stefan does have floating around
somewhere (he ported to D from somewhere else) - but as long as std.conv.to
always calls into C functions when formatting floating point values, then it
can't work with floating points and CTFE any more than writeln can.

Unfortunately, it's typically the case that you can't know whether something
will work at compile time until you try it, because it depends on how the
functions you're calling were implemented, and that's not likely to ever
change. Somehow, everything would have to work at compile time for that not
to be the case.

As for newCTFE, it's my understanding that it doesn't actually support
anything that the current CTFE engine doesn't support; rather it's just
implementing it all in a far more efficient manner so that it's much faster
and doesn't consume ludicrous amounts of memory (which will be a huge
enabler but doesn't necessarily allow any particular code to compile which
can't currently compile unless compilation time or memory usage is what's
currently preventing it). In fact, IIRC, Stefan set it up so that it will
fall back to the old engine in some cases, so it's not even going to fully
replace the old one. However, I haven't been following everything he's been
doing closely, so maybe some of what's he's doing or planning as changed.
Having a much saner CTFE engine will likely make it easier to improve
though. From what I understand about it, the current way that CTFE works is
kind of insane, which is a lot of why it's so inefficient.

- Jonathan M Davis