interface method name collisions

[rntz]

Two interfaces may be declared in the same scope with same-named methods. This leads to problems when a type implements both interfaces:

iface A { fn foo() -> bool; }
iface B { fn foo() -> int; }

// These compile without warnings
fn aa<T:A B>(x: T) -> bool { x.foo() }
fn bb<T:B A>(x: T) -> int { x.foo() }

// These don't compile, due to type error
fn ab<T:A B>(x: T) -> int { x.foo() }
fn ba<T:B A>(x: T) -> bool { x.foo() }

It appears that which method "x.foo()" resolves to depends upon what order the bounds on x's type are declared in. The compiler does catch this ambiguity when we use a specific type rather than quantifying:

impl of A for int { fn foo() -> bool { self > 0 } }
impl of B for int { fn foo() -> int { self } }

fn foo(x: int) -> bool { x.foo() }

The above results in an "error: multiple applicable methods in scope". At the very least this same message should be produced in the first example for all functions (aa,ab,bb,ba).

I would argue that defining two interfaces with same-named methods in the same scope should itself be an error, for the same reason that defining two same-named functions in the same scope is an error: it produces inevitable and irresolvable ambiguity.

[marijnh]

It's not inevitable. You could import one of these impls in another module and use it without problem. The ambiguous case is the use of the method, not its definition, and we' re already reporting that, so I think the current situation is perfectly fine.

[nikomatsakis]

I agree with @marijnh. What might be useful is a method call syntax that makes it possible to disambiguate which in-scope impl you are referring to? Something like a.foo::m() where foo is the impl name. But since, right now at least, impls can have the same name, this would itself still be potentially ambiguous...

[rntz]

@marijnh You're not already reporting that. No error or even warning is given for aa or bb, and the errors for ab and ba do not indicate that the problem was an ambiguous choice of implementation (or rather, of interface; the implementations were already chosen by the person who called us).

It is also not true that you can always disambiguate by implementation name. When a type variable has two bounds (as in aa,bb,ab,ba) which are interfaces with same-named methods, there is no way to select which bound's implementation I am referring to.

For reference, this the compiler output produced:

methodnameclash.rs:7:28: 7:35 error: mismatched types: expected `int` but found `bool` (int vs bool)
methodnameclash.rs:7 fn ab<T:A B>(x: T) -> int { x.foo() }
                                                 ^~~~~~~
methodnameclash.rs:8:29: 8:36 error: mismatched types: expected `bool` but found `int` (bool vs int)
methodnameclash.rs:8 fn ba<T:B A>(x: T) -> bool { x.foo() }
                                                  ^~~~~~~
error: aborting due to previous errors

by compiling this file:

iface A { fn foo() -> bool; }
iface B { fn foo() -> int; }

fn aa<T:A B>(x: T) -> bool { x.foo() }
fn bb<T:B A>(x: T) -> int { x.foo() }

fn ab<T:A B>(x: T) -> int { x.foo() }
fn ba<T:B A>(x: T) -> bool { x.foo() }

fn main() {}

[nikomatsakis]

@rntz ah, indeed, you are correct regarding the lack of reporting or detection in this case. I will fix that at the site of call. I think however that @marijnh is still correct that merely declaring two overlapping ifaces should not be an error. You could do the following, for example:

fn aa<T: A B>(x: T) { with_a(x); with_b(x); }
fn with_a<T: A>(x: T) { x.foo() }
fn with_b<T: A>(x: T) { x.foo() }

No ambiguity arises, despite the fact that both A and B define a method foo()

[rntz]

@nikomatsakis Thank you. Your with_a, with_b solution for disambiguating ifaces had not occurred to me; it's kinda clunky, but on the other hand it's not a situation that will arise often in practice. I think we can consider this issue closed. :)