Inheritance of purity

Michel Fortin michel.fortin at
Thu Feb 16 20:16:25 PST 2012

On 2012-02-17 02:49:40 +0000, Walter Bright <newshound2 at> said:

> 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?

Seems like a good idea to me.

But I think you should make sure error messages mentioning an implied 
inherited attribute says from which subclass the attribute was 
inherited from. For instance:

	override void foo() { impure(); }
	// -> error: cannot call impure() in pure function (purity inherited 

I think such messages will ease code maintenance, because if you later 
edit foo() you might easily forget it is implicitly pure. With this 
message if you somehow need to remove purity you know where to look.

Michel Fortin
michel.fortin at

More information about the Digitalmars-d mailing list