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.
