Congratulations to the D Team!

[Timon Gehr]

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'.