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 reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2036








 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
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 reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2036








 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
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









 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>


accuracy of your statement that it's a valid warning.


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






-------
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






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








 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





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






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