• d-bugmail puremagic.com Apr 25 2008
• "Janice Caron" <caron800 googlemail.com> Apr 25 2008
• d-bugmail puremagic.com Apr 25 2008
• "Janice Caron" <caron800 googlemail.com> Apr 26 2008
• d-bugmail puremagic.com Apr 26 2008
• d-bugmail puremagic.com Apr 26 2008
• "Janice Caron" <caron800 googlemail.com> Apr 26 2008
• d-bugmail puremagic.com Apr 26 2008
• d-bugmail puremagic.com Apr 26 2008
• d-bugmail puremagic.com Apr 26 2008

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.


--