"Don" <[email protected]> wrote in message
news:[email protected]...
Jim Balter wrote:
"Jonathan M Davis" <[email protected]> wrote in message
news:[email protected]...
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.
You understood right.
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.
pure functions must halt, so the attribute let's you tell the compiler
something that it could only figure out with difficulty, if at all.
Being marked as 'pure' is no guarantee that the function will terminate.
A pure function has no side effects; one that doesn't terminate produces no
return value either (throwing an exception is a form of termination). Thus a
pure function that doesn't terminate is a bug. It would be perfectly
reasonable for a compiler to assume that a pure function does terminate but
to put a time limit on how long it spends evaluating it -- which it should
do anyway, since even provably terminating functions can take longer than
the time to the heat death of the universe to complete ... as I noted
before, the halting problem isn't relevant in practice, because even if it
were solvable, there are no time constraints on the solution.
