http://d.puremagic.com/issues/show_bug.cgi?id=2036

           Summary: Hiding rules too restrictive
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: andrei@metalanguage.com


Consider:

class Base
{
    void foo() {}
    void foo(int) {}
}

class Derived : Base
{
    override void foo(int) {}
}

When -w is enabled, the compiler complains that Derived.foo hides Base.foo. In effect, the overriding function properly overrides the second foo in Base but also hides the first foo.

Probably more permissiveness would be helpful in such cases.


-- 

On 25/04/2008, d-bugmail@puremagic.com <d-bugmail@puremagic.com> wrote:
>  class Derived : Base
>  {
>     override void foo(int) {}
>  }
>
>  When -w is enabled, the compiler complains that Derived.foo hides Base.foo. In
>  effect, the overriding function properly overrides the second foo in Base but
>  also hides the first foo.
>
>  Probably more permissiveness would be helpful in such cases.

I disagree. It's a valid warning. To make the warning go away, I think you only have to do:

    class Derived : Base
    {
        override void foo(int) {}
        alias super.foo foo;
    }

(or if that doesn't work, explicitly override both overloads).

http://d.puremagic.com/issues/show_bug.cgi?id=2036





------- Comment #2 from andrei@metalanguage.com  2008-04-26 01:48 -------
(In reply to comment #1)
> On 25/04/2008, d-bugmail@puremagic.com <d-bugmail@puremagic.com> wrote:
> >  class Derived : Base
> >  {
> >     override void foo(int) {}
> >  }
> >
> >  When -w is enabled, the compiler complains that Derived.foo hides Base.foo. In
> >  effect, the overriding function properly overrides the second foo in Base but
> >  also hides the first foo.
> >
> >  Probably more permissiveness would be helpful in such cases.
> 
> I disagree. It's a valid warning.

On what grounds are you saying it's a valid warning? The spirit of the limitation is to prevent code that shouldn't compile from compiling and running with surprising effects. In this case there are no surprising effects if the code does compile, so I refute the claim the warning is valid.

Andrei


-- 

On 26/04/2008, d-bugmail@puremagic.com <d-bugmail@puremagic.com> wrote:
>  On what grounds are you saying it's a valid warning?

I consider it good programming practice that if you're going to override, you should override all overloads, even if only to prove to the compiler that you haven't forgotten they exist.

> so I refute the claim the warning is valid.

You "dispute", not "refute". There's a difference. :-)

http://d.puremagic.com/issues/show_bug.cgi?id=2036





------- Comment #4 from andrei@metalanguage.com  2008-04-26 02:13 -------
(In reply to comment #3)
> On 26/04/2008, d-bugmail@puremagic.com <d-bugmail@puremagic.com> wrote:
> >  On what grounds are you saying it's a valid warning?
> 
> I consider it good programming practice that if you're going to override, you should override all overloads, even if only to prove to the compiler that you haven't forgotten they exist.

This keeps things in the subjective realm. I don't consider good programming practice to override all overloads even when there is no danger that one overload will be called instead of the other.

> > so I refute the claim the warning is valid.
> 
> You "dispute", not "refute". There's a difference. :-)

What I meant to say was that if you want to sustain your claim, you have the burden of proof. So far your first argument was "it's a valid warning", and the second is "I consider avoiding the warning a good programming practice". Both are tenuous. The warning is supposed to warn about a dangerous situations. You need to come with a valid example of something dangerous happening as a consequence of the code going through.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2036





------- Comment #5 from wbaxter@gmail.com  2008-04-26 02:23 -------
((In reply to comment #3)

> > so I refute the claim the warning is valid.
> 
> You "dispute", not "refute". There's a difference. :-)

From m-w.com:

refute
1  : to prove wrong by argument or evidence : show to be false or erroneous
2  : to deny the truth or accuracy of <refuted the allegations>

What's wrong with definition #2 in this case?  He's denying the truth or accuracy of your statement that it's a valid warning.


-- 

On 26/04/2008, d-bugmail@puremagic.com <d-bugmail@puremagic.com> wrote:
> What I meant to say was that if you want to sustain your claim, you have the burden of proof.

I don't think I can prove it - it just seems right to me. I may have to concede this one.

http://d.puremagic.com/issues/show_bug.cgi?id=2036





------- Comment #7 from kamm-removethis@incasoftware.de  2008-04-26 04:35 -------
I think the rationale for the warning is the last case described in http://www.digitalmars.com/d/2.0/hijack.html

Calling the hidden method of Derived via its vtbl did throw an exception for quite a while, but was recently changed to a compile-time warning. I don't think it's sensible for this particular case though, since the addition of foo() can hardly hijack a preexisting call to foo(int).


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2036





------- Comment #8 from brunodomedeiros+bugz@gmail.com  2008-04-26 13:21 -------
So, whenever a function of an overload set is overriden, the language shouldn't
require all functions of the overload set to be overriden, but only those with
the same number of parameters (which are the ones susceptible of being called
errounesly)?
(and those with default parameters values too)


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2036





------- Comment #9 from andrei@metalanguage.com  2008-04-26 14:51 -------
(In reply to comment #8)
> So, whenever a function of an overload set is overriden, the language shouldn't
> require all functions of the overload set to be overriden, but only those with
> the same number of parameters (which are the ones susceptible of being called
> errounesly)?
> (and those with default parameters values too)

Probably even more permissive. The rule of thumb is that the overriding function must not hijack any other in the base class. Consider:

class Base
{
    void foo(int);
    void foo(string[string]);
}

class Derived
{
    override void foo(int);
}

This should go through because there's no chance I could pass an int and expect the overload taking a hash to kick in.


--