How will we fix opEquals?

[spir]

On 02/10/2011 10:26 AM, so wrote:
>> Saying that no one should have to worry about const if they don't want to is a
>> noble though, I suppose, but I don't think that it's entirely realistic. const
>> is part of the language, and some things just plain have to be const to work.
>> And given the prevalence of immutable with regards to threads and the like,
>> you're going to be forced to use const in many cases anyway.
>>
>> I don't think that it's all that big a deal with these 4 functions are const.
>> The impact on the programmer is minimal. They can _almost_ ignore const
>> completely, since they can still ignore it pretty much everywhere else other
>> than with the overriden const Object functions.
>>
>> - Jonathan M Davis
>
> Problem is not having to provide const for these functions, it is the lock-in
> we introduce by marking them const.
> These functions would be const most of the times, if not all. Still, it is hard
> to rule the other case out completely i suppose.

Has it been considered for constness or such constraints not to be inherited? 
(Rather plain functype signature.)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com