Jonathan M Davis wrote:
On Wednesday 21 July 2010 00:09:05 Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (The main
complication is that it has to guess about how many iterations are
performed in loops). Then, when a CTFEable function is called with
compile-time constants as arguments, it could run CTFE on it, even if it
is not mandatory.
Incidentally, having the function being marked as 'pure' doesn't really
help at all for determining if it is CTFEable.
Hmm. As I understood it, it did. But I guess that if it did, the compiler could
technically determine whether a function was actually pure anyway by looking at
its body. All the pure attribute would do is save it the trouble. So, the pure
attribute wouldn't do much in that sense except save the compiler some
computation.
I can certainly see why being pure wouldn't be enough to be CTFEable (since pure
doesn't guarantee anything about whether it's parameters are know at compile
time), but I would have thought that the lack of global state would be required
- at least the lack of global state which isn't known at compile time - for it
to be CTFEable, in which case the pureness would help.
The check for no globals is common to both CTFE and pure, but it's
pretty trivial.
There are functions which are pure but not CTFEable, eg CTFE requires
source code to be available, pure does not.
More interestingly, there are many functions which are CTFEable which
are not pure. It's OK for a CTFE function to modify values which are
reachable through its parameters.
So although CTFEable and pure have significant overlap, neither one is a
subset of the other.
In any case, I'd obviously have to study it up a bit more to understand exactly
what's required for CTFEability. I have some idea, but obviously not enough.
- Jonathan M Davis
