aliasing base methods

[Bill Baxter]

Lars Ivar Igesund wrote:
> Frank Benoit (keinfarbton) wrote:
> 
>> My point is, i want this strange rules to be removed.
>> And I want the override keyword not to be a useless thing.
>>
>> I propose:
>> 1.) make an overload not hide base implementations

What does this mean when combined with number 2?

class Base
{
    int foo(int) { ... }
}
class Derived : Base
{
    // Is this "error: override keyword required"
    // Or is it ok -- not an override but a distict overload leaving
    // foo(int) in tact.
    int foo(float) { ... }
}

If the above code requires 'override' then the meaning of 'override' is 
getting stretched too far.  I that case it isn't overriding anything.

If the above code is OK as is, then that's also a problem because one of 
the most common bugs with overriding is getting the signature wrong.  I 
guess if override is required for actual overriding that means the above 
coder was actually making two mistakes -- forgetting to say 'override' 
*and* getting the signature wrong, but I don't think that combination of 
mistakes would be terribly uncommon.

In short, the above code looks like it's probably a coder error and the 
coder meant to override foo(int).  But you can't be sure.

>> 2.) make the override keyword required, to make it useful.

+1

But note above about not playing nice with exposed base implementations. 
  If overloaded base implementations were not automatically inherited 
then the above would actually give a useful error because foo(float) is 
hiding (and thereby overriding) foo(int), though it is not declared 
'override'.

>> 3.) remove the interface reimplementation rule.

That sounds ok to me -- actually my naive expectation was that that was 
how interfaces already worked.

--bb