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

[Jim Balter]

"Jonathan M Davis" <jmdavisprog at gmail.com> wrote in message 
news:mailman.435.1279700666.24349.digitalmars-d at puremagic.com...
> 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.

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