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