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

Jonathan M Davis jmdavisprog at gmail.com
Wed Jul 21 01:24:10 PDT 2010


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.

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


More information about the Digitalmars-d mailing list