On Saturday, 6 April 2019 at 14:59:18 UTC, ag0aep6g wrote:
On 06.04.19 16:19, Alex wrote:
That is CTFE is CT RTFE where runtime functions are executed
at compile time when the inputs are CT.
You may have the right idea, but the last part of that sentence
is wrong/misleading. CTFE happens when the result is required
at CT. The inputs must be available at CT, but that alone
doesn't trigger CTFE.
Examples:
----
bool f(string s) { return __ctfe; }
void main()
{
import std.stdio: readln;
enum x = f("foo"); /* CTFE */
enum y = f(readln()); /* error, because "readln" can't be
CTFEd */
auto z = f("foo"); /* not CTFE */
}
----
readlin is not a CT function. You misinterpreted what I said.
The function I am talking about is the runtime function(That is a
function that can be run at RT) is to be CTFE'ed.
readln is not to be CTFE'ed.
There is nothing I said that contradicts what you wrote. The
input to f, the RT function to be CTFE'ed cannot be CTFE'ed
because one of it's inputs is not known at CT, that input is
readln, which is another RT that could be CTFE'ed but it cannot
because it's input is not known at CT.
It is obvious that if any RT function(as opposed to a CT function
which obviously is ran at CT. CT functions are pure templates) is
CTFE'able only if all it's inputs are CTFE'able. This creates a
chain reaction. Your chain fails at readln.
Again, you misinterpreted what I said.
I will be clear once more so we are not in disagreement:
That is CTFE is CT RTFE where runtime functions are executed
at compile time when the inputs are CT.
CTFE is compile time runtime function execution. That is, it
exectues *RUNTIME functions* at compile time. I'm not saying that
it executes all runtime functions at compile time, I'm saying it
executes runtime functions. THat is PRECISELY what it does. It
takes a function that is designed or to be run at RT(as far as
the compiler's semantics see it) and it executes it. That, of
course, may fail, but that is irrelevant. The CTFE engine
executes RT functions.
If you think "Well, it will then executes readln()", yes, it
does... but it fails and so the output of readln is not known at
CT and the chain breaks which is why I said the inputs have to be
CT, the input to readln is CT, the input to f is not CT since the
output of readln is not CT. (readln actually has a hidden input
that is not known at CT, which is the keyboard).
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).
By thinking this way there is really no confusion with CTFE,
everyone that programs can program in CTFE without any
complications about meta programming. CTFE is not meta
programming(but one can use meta programming with it for more
complex work). CTFE programming is RT programming but where one
can optimize before RT. It becomes very simple to think about
rather than trying to pretend there is some complex distinction.
