D's treatment of values versus side-effect free nullary functions

[Jim Balter]

"Walter Bright" <newshound2 at digitalmars.com> wrote in message 
news:i2flvi$4io$1 at digitalmars.com...
> Don wrote:
>> Being marked as 'pure' is no guarantee that the function will terminate.
>
> Right, and the compiler makes no attempt to check this, either.

Of course the compiler makes no attempt to check -- that *would* be the 
halting problem, but there's no reason for a compiler to attempt such a 
check even if it could be done.

Pure functions invoked on constant values are excellent candidates for CTFE 
because they have no side effects and are computable at compile time -- if 
they terminate. But pure functions that don't terminate are almost entirely 
pointless; the only non-pointless example I can think of is a kernel''s idle 
process on machines without an interruptable halt instruction. Even if there 
were useful non-terminating pure functions, intentionally putting the 
keyword "pure" on a function that doesn't terminate is doable but dumb. Of 
course, unintentionally doing so is a mistake. But dumbth and mistakes do 
happen, so the compiler can guard against taking forever -- or too long, 
period (Ackermann's Function is a famous example of a pure function that 
takes astronomically long to compute even on small input values -- good luck 
on writing a compiler that can detect such functions) -- by setting a timer. 
If the timer goes off before the computation completes, the compiler should 
abandon CTFE and print a warning message (unless suppressed by a pragma), 
since the function is most likely buggy (this satisfies Rainer Deyke's point 
that errors, including run-on functions, should be detected at compile time 
rather than waiting for runtime).