Is this a bug?

	class A {
		int method();
	}
	class B : A {
		override void method(int);
	}
	void main() {
		B b;
		b.method(123);		// OK
		int x = b.method();	// NG
	}

One might question the wisdom of this kind of overloading, but this is an actual use case in Phobos. In std.range.interfaces, we have:

	interface InputRange(E) {
		@property bool empty();
		@property E front();	// N.B. argumentless overload
		void popFront();
	}

	interface InputAssignable(E) : InputRange!E {
		@property void front(E e); // single argument overload
	}

The current shadowing behaviour makes InputAssignable fail to pass isInputRange, because the derived interface's .front method shadows the base class's, even though they are non-conflicting overloads(!).


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly

On Monday, 20 March 2017 at 19:57:03 UTC, H. S. Teoh wrote:
> Is this a bug?

No, that's intentional, you have to merge the overload sets with alias, same as if you imported them from two separate modules.

http://dlang.org/hijack.html

On Monday, March 20, 2017 20:13:12 Adam D. Ruppe via Digitalmars-d wrote:
> On Monday, 20 March 2017 at 19:57:03 UTC, H. S. Teoh wrote:
> > Is this a bug?
>
> No, that's intentional, you have to merge the overload sets with alias, same as if you imported them from two separate modules.
>
> http://dlang.org/hijack.html

Yeah. Creating new overloads for functions from a base class gets annoying fast. It's probably great from the standpoint of avoiding function hijacking bugs, but as with many of the restrictions that we get as part of the attempts to avoid function hijacking in D, the result can be a bit annoying in practice.

- Jonathan M Davis