Inheritance of purity

[Timon Gehr]

On 02/17/2012 04:59 AM, bearophile wrote:
> Jonathan M Davis:
>
>> 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.
>
> This is a problem.
>

It is not a problem at all. This can happen in C++:

struct S: T{
     void foo(){ ... }
}

int main(){
     T* x = new S();
     x->foo(); // what will this do? No way to know without looking up 
T, bug prone.
}

This is the worst-case scenario for D:

class S: T{
     void foo(){ ... }
}

void bar()pure{
     T x = new S;
     S.foo(); // see below
}

'foo' sounds like a pure method name... Hit compile... Oh, it is not 
pure... It should be! Look up class T, patch in purity annotation, 
everything works - awesome!


The analogy is so broken it is not even funny.


> On the other hand I presume Walter is now converting Phobos all at once to fix const correctness, so he's writing tons of attributes. So he desires to quicken this boring work.
>
> On the other hand fixing const correctness in Phobos is not a common operation, I think it needs to be done only once. Once one or two future DMD versions are out, programmers will not need to introduce a large amount of those annotations at once. So "fixing" forever D2 for an operation done only once seems risky, especially if future IDEs will be able to insert those annotations cheaply.
>
> So a possible solution is to wait 2.059 or 2.060 before introducing this "Inheritance of purity" idea. I think at that time we'll be more able to judge how much useful this feature is once Phobos is already fully const corrected and no need to fix a lot of code at once exists.
>
> Another idea is to activate this "Inheritance of purity" only if you compile with "-d" (allow deprecated features) for few months and then remove it, to help porting of today D2 code to const correctness in a more gradual way.
>
> Bye,
> bearophile

Are you really suggesting that making code const correct and the right 
methods pure etc. is not a common operation?