Bug 7534 – Allow attribute-overloading of an overridden method
Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-02-17T11:34:00Z
Last change time
2012-04-20T01:17:20Z
Keywords
pull
Assigned to
nobody
Creator
timon.gehr
Comments
Comment #0 by timon.gehr — 2012-02-17T11:34:45Z
Also see: http://d.puremagic.com/issues/show_bug.cgi?id=3757
class C{
void foo(){}
}
class D : C{
override void foo(){}
void foo()const{}
}
Currently this is illegal. Both child class methods are assumed to override the parent class method:
Error: D.foo multiple overrides of same function
Only the first child class method should override the parent class method and the second child class method would introduce an additional overload on const.
Similar observations apply to shared/immutable/inout functions.
Comment #1 by yebblies — 2012-02-18T01:36:00Z
I assume this is what Walter meant when he said contravariance causes problem with overloading.
Are you sure it's a good idea to have the first overload selected? This would mean removing it would make the second overload the overrider. While it will be different once omitting 'override' is an error, override does not change semantics in any other case, it just confirms and enforces what the compiler determines anyway.
Comment #2 by timon.gehr — 2012-02-18T03:26:40Z
The idea is that code like this would be allowed too:
class C{
void foo(){}
}
class D : C {
alias C.foo foo; // inherit from super class
void foo()const{} // additional overload
}
I agree that implementing this requires making omission of override an error.
Comment #3 by timon.gehr — 2012-02-18T03:33:58Z
NVM, that would break code like the following:
class C{
void foo(){writeln(1);}
void foo()immutable{writeln(2);}
}
class D : C {
alias C.foo foo;
void foo()const{writeln(3);} // currently overrides 2
}
I don't know if it is worth the effort.
Comment #4 by yebblies — 2012-02-18T04:02:42Z
Heh, that last example should either override both or be an ambiguity error.
Comment #5 by deadalnix — 2012-02-24T04:32:05Z
As I explained somewhere in the news group, the current behavior is inconsistent.
We have to choose is const is a characteristic of the method or of its arguments.
If it is a characteristic of its argument (the hidden argument this), then const and non const method are 2 different methods, and shouldn't override each other.
If this is a characteristic of the method, then we shouldn't be able to define both const and non const version of the same method, just like we cannot define both pure and impure version of a same function.
This problem is closely related to the return type const qualifier one, both are symptoms of the same misconception in D spec.
Comment #6 by k.hara.pg — 2012-03-03T07:01:05Z
I think this is almost same as issue 3757, and I think additional overload in derived class is useful and should work.
Example:
// after fixing object const correctness (bug 1824)
class Object {
bool opEquals(const Object o);
//...
}
class C {
alias super.opEquals opEquals;
// additional overload for mutable object equality
override bool opEquals(Object o) {
// special processing, e.g. caching
return super.opEquals(o);
}
}