Le 17/02/2012 03:49, Walter Bright a écrit :
Given:class A { void foo() { } } class B : A { override pure void foo() { } } This works great, because B.foo is covariant with A.foo, meaning it can "tighten", or place more restrictions, on foo. But: class A { pure void foo() { } } class B : A { override void foo() { } } fails, because B.foo tries to loosen the requirements, and so is not covariant. Where this gets annoying is when the qualifiers on the base class function have to be repeated on all its overrides. I ran headlong into this when experimenting with making the member functions of class Object pure. So it occurred to me that an overriding function could *inherit* the qualifiers from the overridden function. The qualifiers of the overriding function would be the "tightest" of its explicit qualifiers and its overridden function qualifiers. It turns out that most functions are naturally pure, so this greatly eases things and eliminates annoying typing. I want do to this for @safe, pure, nothrow, and even const. I think it is semantically sound, as well. The overriding function body will be semantically checked against this tightest set of qualifiers. What do you think?
Walter, I think you get the const qualifier wrong. const does not qualify the method, but the hidden parameter "this".
I don't think this is a good idea for const/immutable . Simply because you may want to have both defined, and it lead to ambiguity.
However, for pure, @safe, nothrow and basically any qualifier that effectively qualify the function, it is a great idea.
BTW, to keep the source code understandable, this should be enabled only if the overriden keyword is present. So if you see a function with overriden, you'll know about thoses qualifier possibly being present. If the overriden isn't present, the current behaviour should be preserved.
