Bug 2036 – Hiding rules too restrictive

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, [email protected] <[email protected]> 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).

(In reply to comment #1) > On 25/04/2008, [email protected] <[email protected]> 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, [email protected] <[email protected]> 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. :-)

(In reply to comment #3) > On 26/04/2008, [email protected] <[email protected]> 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.

((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, [email protected] <[email protected]> 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.

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

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)

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

This works in 2.019. Won't be changed for 1.0.

Sounds great, thanks. Are there any more cases when shadowing causes a runtime error? Let's expose all of them during compilation if needed.