Congratulations to the D Team!

[deadalnix]

On 11/07/2012 18:30, H. S. Teoh wrote:
> On Wed, Jul 11, 2012 at 05:27:01PM +0200, deadalnix wrote:
>> On 11/07/2012 17:03, Jakob Ovrum wrote:
> [...]
>>> This solution is not for allowing people to use lazy computation in
>>> their const overrides, it's for allowing people to still use
>>> opEquals, toString etc. even if their implementations cannot and
>>> should not be const.
>>>
>>
>> In this case, they have function that does something else than
>> compare test for equality, etc . . . The overload make no sense here
>> in the first place, and the fact that const break such thing isn't a
>> problem. This is the other way around, the fact that const break
>> such a practice is good.
>
> 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.
>

Either the structure is mutable, and you have to recompute anyway, or 
the structure is trully const and thing can be computed up-front.