Purity

Bruno Medeiros brunodomedeiros+spam at com.gmail
Wed Mar 23 07:48:25 PDT 2011


result1 ==On 11/02/2011 22:51, Simen kjaeraas wrote:
> Bruno Medeiros <brunodomedeiros+spam at com.gmail> wrote:
>
>> In this code sample if the optimization is applied on the second call
>> to func, it would cause different code with be executed: the else
>> clause instead of the then clause. Obviously this is not acceptable
>> for an optimization, even if such code would be rare in practice.
>
> Ah yes, I see now. I could argue that 'is' is cheating. :p
>
> I believe actually, that pure is only said to promise that the returned
> values should be such that func(args) == func(args), not accounting for
> overloaded operators.
>

That still would not be guaranteed. In the example I mentioned before, 
it already happens that
   (result1 == result2) == false

I think that the concession that pure will be allowed to allocate memory 
does inescapably remove some of the guarantees that pure functions offer 
(like that one that the return value depends only on the arguments).
One possible fix to this would be to say that the allocated memory must 
be temporary (used only during the execution of the pure function). Thus 
you would not be able to return any newly-allocated value. But I don't 
know if this further restriction is desirable or not. I don't remember 
if this aspect of memory allocation in pure functions was 
discussed/thought-out extensively or not. (it probably needs to)


-- 
Bruno Medeiros - Software Engineer


More information about the Digitalmars-d mailing list