Proposition for change in D regarding Inheriting overloaded methods

[Regan Heath]

Bruno Medeiros wrote:
> Walter Bright wrote:
>> Regan Heath wrote:
>>
>> There is no runtime check or cost for it. The compiler just inserts a 
>> call to a library support routine in D's vtbl[] entry for B.set(int).
>>
>>> Is this done at runtime instead of compile time because the 
>>> parameters cannot always be determined at compile time?
>>
>> Yes.
>>
> 
> Huh? I don't understand this, how come it's not possible to detect it at 
> compile time? Doesn't the full signature of all methods from both parent 
> and child class have to be know at compile time?

The feature(1) would be implemented at the call site.  In this example:

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();
}

When compiling b.set(3) the compiler determines the type of '3' and 
performs it's checking based on that type.

IANACW (I am not a compiler writer) so I can't think of a case but 
Walters reply seems to indicate that there are cases where the type of 
the parameter cannot be determined at compile time.

Regan

(1) The feature being the one described by Steven where the compiler 
searches all base classes of D for any overload of 'set' not implemented 
in D accepting 'int' or 'int' by implicit conversion and gives an error.