Inheritance of purity

Jason House at
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 is covariant with, 
> meaning it can "tighten", or place more restrictions, on foo. 
> But:
>     class A { pure void foo() { } }
>     class B : A { override void foo() { } }
> fails, because 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 

Initial code:
class A{
   void foo(int) const;
   void foo(float) const;
class B{
   alias 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