CTFE & code generators based on PEG grammars?

ag0aep6g anonymous at example.com
Sun Apr 7 09:43:09 UTC 2019


On 07.04.19 05:32, Alex wrote:
> readlin is not a CT function. You misinterpreted what I said.

Yeah, bad example from me. This would probably have been better:

----
auto v = "foo";
enum y = f(v); /* Error: variable v cannot be read at compile time */
----

Also, the `readln` example wasn't meant to contradict anything you said. 
The one after it (`auto z = f("foo"); /* not CTFE */`) is supposed to 
clarify your statement that "CTFE [happens] when the inputs are CT". 
It's true that CTFE can only happen when the inputs are known at CT, but 
that alone doesn't force CTFE.

[...]
> If you think of it the way I have said and understand what it means then 
> it is much easier to understand CTFE because you really are just doing 
> "normal" programming of RT functions but you just execute them at CT if 
> possible(and the possibility simply is if the inputs are known at CT).

There's that same slight unclarity again. You may have the right 
understanding of CTFE, but your phrasing is a bit misleading. CTFE 
doesn't kick in whenever it's possible to precompute something at CT. It 
only kicks in when the result is required at CT by language rules.

[...]
> CTFE programming is RT 
> programming but where one can optimize before RT.

Optimization is not the only use for CTFE. It can also be used to 
generate compile-time constants, like lengths for static arrays or D 
code itself that is then mixed in. Can't do that stuff with run-time calls.


More information about the Digitalmars-d-learn mailing list