Inheritance of purity

Kapps opantm2+spam at
Thu Feb 16 21:08:52 PST 2012

On Friday, 17 February 2012 at 03:24:50 UTC, Jonathan M Davis 
> On Thursday, February 16, 2012 18:49:40 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?
> No. Absolutely not. I hate the fact that C++ does this with 
> virtual. It makes it so that you have to constantly look at the 
> base classes to figure out what's virtual and what isn't. It 
> harms maintenance and code understandability. And now you want 
> to do that with @safe, pure, nothrow, and const? Yuck.
> I can understand wanting to save some typing, but I really 
> think that this harms code maintainability. It's the sort of 
> thing that an IDE is good for. It does stuff like generate the 
> function signatures for you or fill in the attributes that are 
> required but are missing. I grant you that many D developers 
> don't use IDEs at this point (at least not for D) and that 
> those sort of capabilities are likely to be in their infancy 
> for the IDEs that we _do_ have, but I really think that this is 
> the sort of thing that should be left up to the IDE. Inferring 
> attribtutes like that is just going to harm code 
> maintainibility. It's bad enough that we end up with them not 
> being marked on templates due to inferrence, but we _have_ to 
> do it that way, because the attributes vary per instantiation. 
> That is _not_ the case with class member functions.
> Please, do _not_ do this.
> - Jonathan M Davis

In the situation where the IDE writes it for you, said IDE will 
help you only when you write the code.

In the situation where the IDE tells you what they are (through 
something like hovering over it), it will help you no matter who 
writes the code. It is also significantly easier to implement, 
particularly taking into consideration things like style, 
comments, etc.

More information about the Digitalmars-d mailing list