https://dlang.org/spec/function.html#function-inheritance

Consider this snippet from the documentation:

class A
{
    int foo(int x) { ... }
    int foo(long y) { ... }
}

class B : A
{
    override int foo(long x) { ... }
}

void test()
{
    B b = new B();
    b.foo(1);  // calls B.foo(long), since A.foo(int) not considered
    A a = b;

    a.foo(1);  // issues runtime error (instead of calling A.foo(int))
}


I ran into this the other day, where I had a function of the same name in a child class, and found that all functions in the parent of the same name now became hidden, unless I add an alias statement.

After a bit of reading, I understood the rule and how it works, but what I'm missing is the "why".  Why is it desirable to hide methods from a parent class which have the same name (but different arguments) as a method in a class?

On 14.01.19 10:10, Vijay Nayar wrote:
> After a bit of reading, I understood the rule and how it works, but what I'm missing is the "why".  Why is it desirable to hide methods from a parent class which have the same name (but different arguments) as a method in a class?

https://dlang.org/articles/hijack.html#derived-class-members

On Mon, 14 Jan 2019 09:10:39 +0000, Vijay Nayar wrote:
>      a.foo(1);  // issues runtime error (instead of calling
> A.foo(int))

Calling the function doesn't issue any sort of error. Overriding one overload without overloading or explicitly aliasing in the rest issues a compile-time error.

If you got a runtime error instead, please create a bug report.

> I ran into this the other day, where I had a function of the same name in a child class, and found that all functions in the parent of the same name now became hidden, unless I add an alias statement.

If the functions from the parent class are hidden but your code compiles, please create a bug report.

On 1/14/19 2:30 PM, Neia Neutuladh wrote:
> On Mon, 14 Jan 2019 09:10:39 +0000, Vijay Nayar wrote:
>>       a.foo(1);  // issues runtime error (instead of calling
>> A.foo(int))
> 
> Calling the function doesn't issue any sort of error. Overriding one
> overload without overloading or explicitly aliasing in the rest issues a
> compile-time error.
> 
> If you got a runtime error instead, please create a bug report.
> 
>> I ran into this the other day, where I had a function of the same name
>> in a child class, and found that all functions in the parent of the same
>> name now became hidden, unless I add an alias statement.
> 
> If the functions from the parent class are hidden but your code compiles,
> please create a bug report.
> 

Well, for sure, the documentation needs to be updated!

It was 2.068 that removed the HiddenFuncError, and made this a compile error instead. If your compiler is that or newer, definitely file a bug report.

-Steve

On Wednesday, 16 January 2019 at 17:01:06 UTC, Steven Schveighoffer wrote:
> On 1/14/19 2:30 PM, Neia Neutuladh wrote:
>> On Mon, 14 Jan 2019 09:10:39 +0000, Vijay Nayar wrote:
>>>       a.foo(1);  // issues runtime error (instead of calling
>>> A.foo(int))
>> 
>> Calling the function doesn't issue any sort of error. Overriding one
>> overload without overloading or explicitly aliasing in the rest issues a
>> compile-time error.
>> 
>> If you got a runtime error instead, please create a bug report.
>> 
>>> I ran into this the other day, where I had a function of the same name
>>> in a child class, and found that all functions in the parent of the same
>>> name now became hidden, unless I add an alias statement.
>> 
>> If the functions from the parent class are hidden but your code compiles,
>> please create a bug report.
>> 
>
> Well, for sure, the documentation needs to be updated!
>
> It was 2.068 that removed the HiddenFuncError, and made this a compile error instead. If your compiler is that or newer, definitely file a bug report.
>
> -Steve

It's a compile error, and it says that one should use alias as well.  I was just surprised and I hadn't thought of why this alias would be needed.  Based on the recommendation I found the language documentation, but there was no link to the article explaining the rationale.  But I'm glad I read that article, it makes a lot more sense now.

On Wed, 16 Jan 2019 12:01:06 -0500, Steven Schveighoffer wrote:
> It was 2.068 that removed the HiddenFuncError, and made this a compile error instead. If your compiler is that or newer, definitely file a bug report.

Oh god, that must have been awful. I'm glad we're no longer in those benighted times.

On 1/16/19 12:25 PM, Neia Neutuladh wrote:
> On Wed, 16 Jan 2019 12:01:06 -0500, Steven Schveighoffer wrote:
>> It was 2.068 that removed the HiddenFuncError, and made this a compile
>> error instead. If your compiler is that or newer, definitely file a bug
>> report.
> 
> Oh god, that must have been awful. I'm glad we're no longer in those
> benighted times.
> 

I will never forget those times! This subject was actually my first reason for posting to the forums :)

https://forum.dlang.org/post/f8qrgg$12q8$1@digitalmars.com

Good times...

-Steve