Congratulations to the D Team!

[deadalnix]

On 11/07/2012 19:46, Andrei Alexandrescu wrote:
> On 7/11/12 1:04 PM, Timon Gehr wrote:
>> On 07/11/2012 06:45 PM, Andrei Alexandrescu wrote:
>>> On 7/11/12 12:30 PM, H. S. Teoh wrote:
>>>> It *is* a problem when you're talking about abstractions. If I have
>>>> million node binary trees and I'm testing for equality, I'd like to be
>>>> able to cache the results. But being forced to use const means I can't
>>>> cache anything. And this isn't just about caching; if my tree is
>>>> partially stored in the database, and I have a DB connection object in
>>>> my tree class, then I can't use opEquals because I can't modify the DB
>>>> state (which is impractical if I have to actually use it to make DB
>>>> queries -- the DB engine may have to cache DB pages, etc.). Any
>>>> abstraction of opEquals beyond the bitwise level cannot be implemented.
>>>
>>> How about the static hash/cache?
>>>
>>> Andrei
>>
>> Will break horribly as soon as it is discovered that the methods should
>> be pure as well.
>
> I don't think they should be pure. Do you have reasons to think otherwise?
>
> Andrei

I think they should. Comparing the same object 2 time should 
definitively have the same result back, otherwise things will go 
horribly wrong soon enough.