Proposition for change in D regarding Inheriting overloaded methods

Regan Heath regan at netmail.co.nz
Tue Aug 7 10:49:50 PDT 2007


Steven Schveighoffer wrote:
> So my proposal is to change the specification so that:
> 
> If there is a class A, which is a base class of class B, where A defines a 
> method foo(args), and B defines a method foo(args2), such that the types of 
> args2 cannot be implicitly converted to args, and B does not define 
> foo(args), then the definition of B.foo(args) shall be implicitly aliased to 
> A.foo(args).  If, using the same assumptions, args2 can be implicitly 
> converted to args, then the compiler should fail to compile B indicating 
> that the user must define B.foo(args) by override or by alias.
> 
> I believe this will give us the best of both camps, and allow much less code 
> to be released with silent bugs than the current implementation.
> 
> Let the hole shooting begin...

I like it.  In fact it solves the existing problem exhibited by the 
original example 2!

Here are our original examples given by Walter and used to support the 
current C++ like behaviour.

-----------------------------------
class X1 { void f(int); }

// chain of derivations X(n) : X(n-1)

class X9: X8 { void f(double); }

void g(X9 p)
{
     p.f(1);    // X1.f or X9.f ?
}
-----------------------------------
class B
{    long x;
      void set(long i) { x = i; }
     void set(int i) { x = i; }
     long squareIt() { return x * x; }
}
class D : B
{
     long square;
     void set(long i) { B.set(i); square = x * x; }
     long squareIt() { return square; }
}
long foo(B b)
{
     b.set(3);
     return b.squareIt();
}
-----------------------------------

Under your proposal these would both be classify as "incorrectly 
implemented override"'s and fail to compile with an error.

In example 1 the error would occur when compiling X9.  In example 2 the 
error would occur when compiling D.  In both cases the addition of 
'alias' or an exact override for the 'int' method from the base will 
resolve the error.

In example 1, if other overloads existed in X2 thru X8 i.e. "void 
f(short);" then both "void f(int);" and "void f(short);" would need to 
be aliased or defined in X9 to resolve the error.  This seems to 
indicate that all base classes all the way back to the root need to be 
examined, that could be complex...

As I mentioned earlier your proposal will solve the existing problem 
caused by example 2, which under both C++ and Java like implementations 
calls B.set(int) then D.squareit() resulting in 0 instead of 9.

That, combined with the implicit alias of overloads where no implicit 
conversion is possible and I think it will be a feature which is both 
safe and intuitive.

I'm interested to see what other people think.

Regan



More information about the Digitalmars-d mailing list