Inheritance of purity

[James Miller]

On 17 February 2012 15:49, Walter Bright <newshound2 at digitalmars.com> 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?

Makes sense to me, should also ease some pains that I've seen
discussed in other threads regarding the utility of pure and const,
etc. In terms of intuitiveness, I think this makes more sense, since
overrides are explicit.

I'm with Teoh that it might make it a bit more difficult to understand
code, but to some extent that is partially a documentation problem,
which is always an issue, no matter what.

--
James Miller