www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2036] New: Hiding rules too restrictive

reply d-bugmail puremagic.com writes:
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.


-- 
Apr 25 2008
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
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).
Apr 25 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
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 --
Apr 25 2008
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
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. :-)
Apr 26 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
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. --
Apr 26 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
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. --
Apr 26 2008
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
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.
Apr 26 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
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).


-- 
Apr 26 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
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)


-- 
Apr 26 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
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. --
Apr 26 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2036


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




------- Comment #10 from bugzilla digitalmars.com  2008-10-10 17:12 -------
This works in 2.019. Won't be changed for 1.0.


-- 
Oct 10 2008
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2036





------- Comment #11 from andrei metalanguage.com  2008-10-10 17:52 -------
Sounds great, thanks. Are there any more cases when shadowing causes a runtime
error? Let's expose all of them during compilation if needed.


-- 
Oct 10 2008