Congratulations to the D Team!

[Timon Gehr]

On 07/11/2012 07:46 PM, 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 be pure as much as I think they should be const.

The reasoning is analogous for both.

We have immutable class instances that want to provide the methods => 
make them const.

We have pure functions that want to provide the methods => make them pure.

This reasoning is not taking into account the whole picture because

We have implementations of those methods that want to use non-const
methods in their implementation. (eg. database connection)

We have implementation of those methods that want to use non-pure
methods in their implementation (eg. database connection, logging)