Inheritance of purity

[deadalnix]

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.