newCTFE Status August 2019 (page 3)

September 01, 2019
Re: newCTFE Status August 2019
Posted by Jonathan M Davis
in reply to Jon Degenhardt
Permalink
Jonathan M Davis
Posted in reply to Jon Degenhardt
Permalink
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
Forums
