why are opCmp and opEquals not pure.

[Jonathan M Davis via Digitalmars-d]

On Thursday, 17 September 2015 at 19:30:09 UTC, H. S. Teoh wrote:
> On Thu, Sep 17, 2015 at 06:37:04PM +0000, Stefan Koch via 
> Digitalmars-d wrote:
>> Hi,
>> is there any reason why opCmp and opEquals are not pure ?
>> I would argue it is very counter-intuitive to mutate any state 
>> when
>> comparing objects.
> [...]
>
> The way I understand it, this is a historical accident: opCmp 
> and opEquals date back to the days before the const system was 
> introduced to D, so they were never originally annotated. When 
> the const system was introduced, a good amount of code is 
> already using opCmp and opEquals, and some of them may mutate 
> state (e.g., cache the result of previous comparisons in the 
> object if the comparison operation is expensive), so adding the 
> annotations would break existing code.
>
> At the time, a lot of the affected code was in Phobos, where 
> there was a giant tangle of dependencies where changing the 
> const annotation on a single function would percolate to almost 
> half of the entire Phobos (if not more), breaking many other 
> seemingly-unrelated things (and introducing potential for 
> breakage of user code that use those things), so it was 
> difficult to make the transition.
>
> Since that time, there has been talk of removing opCmp and 
> opEquals from Object altogether, but so far we haven't managed 
> to do this yet.

It's not just a question of existing code. It can be perfectly 
legitimate to cache data or even to have to talk to stuff outside 
your program (e.g. in a database) to check for equality, even if 
that's not what the vast majority of programs should be doing. 
So, requiring pure, const, @safe, or any attribute is overly 
restrictive, particularly considering that D is supposed to be a 
systems language. At the same time, if we don't have those 
attributes on the virtual functions on Object, then folks that do 
want to use those attributes are screwed (e.g. using == with 
const class objects only works because of a hack in druntime 
which casts away const and risks incorrect behavior). And that's 
why it was decided that we really needed to remove them from 
Object and just leave it up to the derived classes to declare 
them and choose what attributes they would use:

https://issues.dlang.org/show_bug.cgi?id=9769
https://issues.dlang.org/show_bug.cgi?id=9770
https://issues.dlang.org/show_bug.cgi?id=9771
https://issues.dlang.org/show_bug.cgi?id=9772

Unfortunately, there are a number of technical issues in doing so 
from compiler bugs to changes that need to be made in druntime 
(e.g. changing the built-in AA implementation), and so while some 
work has been done towards that goal, we have yet to get there. 
And until we do, we're always going to have attribute problems 
with any of the virtual functions on Object.

- Jonathan M Davis