Inheritance of purity
Jason House
jason.james.house at gmail.com
Sun Feb 26 09:39:48 PST 2012
On Friday, 17 February 2012 at 02:49:40 UTC, Walter Bright wrote:
> 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?
I'm still not convinced about this apply to const. Consider this
example:
Initial code:
class A{
void foo(int) const;
void foo(float) const;
}
class B{
alias A.foo foo;
override void foo(int);
}
Revision to class A:
class A{
void foo(int);
void foo(int) const;
void foo(float);
void foo(float) const;
}
When the user recompiles, there will be no errors or warnings.
All uses of foo(int) through a const B will revert to using the
base class's implementation.
More information about the Digitalmars-d
mailing list