Inheritance of purity

[deadalnix]

Le 18/02/2012 22:18, Timon Gehr a écrit :
> On 02/18/2012 10:06 PM, deadalnix wrote:
>> Le 18/02/2012 16:04, Timon Gehr a écrit :
>>> For them, it is certainly safe. It is questionable how large the
>>> effective benefit is for const, since the const qualifier would be
>>> inherited for the method only, but not for its parameters.
>>>
>>
>> The const qualifier does NEVER qualify a function. This is a
>> misconception.
>
> I don't care whether or not it is a misconception. It is how the
> language is defined. If you want to change this, file an enhancement
> request.
>
>> In what we call const function, what is const is the
>> hhidden parameter "this", not the function.
>
> Both are const. Ask the compiler.
>
> struct S{
> void foo()const{
> static assert(is(typeof(this)==const));
> static assert(is(typeof(foo)==const));
> }
> }
>
> In fact, the incident that the method is const is what enables
> contravariant overriding of mutable/immutable by const methods. (This is
> not supported for the explicit formal parameter types.)

The spec is incosistent.

Either the function isn't const, and only this is const. In this case 
the inference here doesn't make any sense. const and non const are 
different and because parameters are differents.

Or we consider that const qualify both the hidden parameter AND the 
function. In this case, you mustn't be able to define both a const and a 
non const version of a function. Just like a function is pure or non 
pure, and you cannot define twice the same function, with one pure 
version and an impure one. This has the advantage of imporving 
covariance in overload, but if you can define both const and non const 
version of a function, then you ends up with crazy situation where all 
overload change meaning if I add a function is the base class - with no 
warning, no errors, just a completely fuckup program and hours of happy 
digging in the code to clean this up.