A type acquires two interfaces that each supply a body for a method with the same name and signature. Compare where different languages report that conflict and what they force the programmer to write.

## The situation Once interfaces are allowed to carry method bodies, a type can acquire two bodies for the same signature from two different supertypes. Every language that permits interface defaults has had to invent a rule, and the rules differ in three dimensions: **when** the conflict is detected, **who** must write the disambiguation, and **what** the default winner is if there is one. ## Java: detected at the class, fixed by overriding Java's rule is deliberately conservative. If a class inherits two `default` methods with the same signature from unrelated interfaces, the class does not compile. There is no precedence to memorise and no silent winner; the compiler simply refuses and you must override the method in the class. Inside that override, `A.super.m()` names one specific inherited body — a syntax that exists only for this situation. Two secondary rules matter. A method inherited from a **class** beats any interface default ("class wins"), which keeps existing code stable when a new default appears. And a **more specific interface** beats a less specific one: if `B extends A` and both define `m`, `B`'s body wins with no error. The cost of detecting at the class is a source-compatibility hazard: an upstream library adding a default method can break a downstream class that already implements two interfaces, even though nothing in that class changed. ## C#: most specific wins, and defaults are not class members C# 8 default interface members follow a most-specific-override rule from the same family, and unrelated conflicts are likewise an error the implementer must resolve. The distinctive part is elsewhere: a default body is **not** part of the implementing class's member set. Given `class S : IA` where `IA` provides `M`, `new S().M()` does not compile; `((IA)new S()).M()` does. The practical consequence is that the object's behaviour depends on the *static type of the reference* used to call it, which is a different world from Java's guarantee that a default is just a normal virtual method. ## Rust: nothing is wrong until you call Rust traits may both provide `fn m(&self)` with default bodies, and a struct may implement both. That code compiles without complaint, because a trait impl is a separate namespace rather than a contribution to the type's own member list. The ambiguity surfaces at the **call site**: `s.m()` fails with "multiple applicable items in scope", and you write `A::m(&s)` or the fully-qualified `<S as A>::m(&s)` to pick one. This is a genuinely different placement of the same decision. Rust never forces a type to have one answer for `m`; it forces each *caller* to say which trait's `m` it meant. A library can therefore add a trait impl that would be a compile error in Java and it only affects call sites that use both traits in scope. ## Swift: static dispatch means the conflict may not be reported at all Swift protocol extensions provide bodies too, but only members that are **declared protocol requirements** get a witness-table entry and dynamic dispatch. Members that exist only in an extension are resolved on the declared type of the reference. So a value conforming to two protocols whose extensions both supply the same helper can invoke either, depending on how it is typed at the call site, and a conformer's own method of the same name may be skipped entirely when the value is held as a protocol type. The compiler complains only when it genuinely cannot pick. ## Scala's answer, for contrast Scala resolves conflicts by linearising the mixin order — the rightmost trait wins, and `super[T].m()` names a specific one. That mechanism belongs to the traits and mixins discussion; the point here is that it is a fourth answer to the same question, this time with a deterministic winner and no error at all. ## What this means in practice - **Never rely on "the compiler will catch it" being universal.** It is true in Java at the class, true in Rust at the call, and largely false in Swift for extension-only members. - **Treat adding a default body upstream as a potentially source-breaking change** in Java and C#, and document it as such in library release notes. - **Keep interface defaults thin and non-overlapping.** The common naming victims are generic verbs: `close`, `render`, `size`, `merge`, `validate`. Two independently designed interfaces converge on those names easily. - **When you must disambiguate, delegate rather than duplicate.** Overriding and calling one specific inherited body keeps a single implementation of the behaviour; copying the body into the class quietly forks it.