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

[Don]

Jim Balter wrote:
> "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; 

It's a bug.

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).

I don't think you can say that it's "most likely buggy". A function to 
calculate pi, for example, is a pure function that may take days to run.