Inheritance of purity

[Bruno Medeiros]

On 17/02/2012 02:49, 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?

Sounds like a good idea.
I would even add to this that it might be useful to have similar syntax 
that would allow to define an override method without having to specify 
the return type nor the parameters of the overridden method. Sometimes 
in class hierarchies there is a lot of redundancy when overriding 
methods and it could be a nice small feature to reduce that (especially 
for methods with lots of parameters).

class Foo {
	int num;
	
	override opEquals {
		if(cast(Foo) o is null)
			return false;
		return this.num == (cast(Foo) o).num;
	}
	
	override toString {
		return to!(string)(num);
	}
	
}

-- 
Bruno Medeiros - Software Engineer