Congratulations to the D Team!

[deadalnix]

On 11/07/2012 17:49, Timon Gehr wrote:
> On 07/11/2012 05:27 PM, deadalnix wrote:
>> On 11/07/2012 17:03, Jakob Ovrum wrote:
>>> On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu wrote:
>>>> I was a long-time proponent of this. It's less exciting than it may
>>>> seem actually.
>>>>
>>>> (a) Classes that work with const just fine incur one extra virtual
>>>> call. I think this can be avoided by having the compiler plant the
>>>> same pointer for the const and non-const version in the vtable.
>>>>
>>>> (b) Classes that can't do as little as one of these four operations
>>>> without mutating the object are completely excluded from the
>>>> immutability system, even if they'd otherwise benefit from it. Even
>>>> those that don't "care" they need to actively _work_ on not caring,
>>>> which doesn't sit well.
>>>>
>>>> So I don't see this as a viable solution to people who are fine with
>>>> const, but would like to use e.g. some lazy computation.
>>>>
>>>>
>>>> Andrei
>>>
>>> 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.
>
> I think this posts roots in a misunderstanding of 'cannot and should not
> be const'.

If it cannot and should not be const, it isn't a comparison or an 
equality test, it is another operation altogether that is performed.