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?
