You need to add an operation to an abstraction that code outside your control already implements, without breaking those implementations. Compare the mechanisms offered by Java's default methods, C#'s default interface members, Swift's protocol extensions and Go's optional-interface upgrade.

## Why adding a method is a breaking change at all An abstraction is a promise about what implementers provide. Adding a required operation raises the bar for every existing implementer, and all of them fail to compile — or, in dynamic languages, fail the first time the new operation is called. When the implementers are inside your repository this is a mechanical edit. When they are in code you do not control, it is a breaking release, and the mechanism your language gives you determines whether you can avoid one. ## Java: a default body, dispatched normally Java 8 added default methods so that `Collection` could gain `stream()` and `forEach()` without breaking every implementation ever written. A default method has a body on the interface; a class that does not override it inherits that body, and a class that does override it wins, always, because dispatch is ordinary virtual dispatch. If a class inherits conflicting defaults from two interfaces, the compiler refuses and demands an explicit override — the diamond is surfaced rather than silently resolved. The real limitation is state: interfaces cannot hold fields, so a default method can only be written in terms of operations the interface already has. That is a genuine design constraint, and it is why some evolutions cannot be done with defaults at all. ## C#: the same words, a different rule C# 8 introduced default interface members with a deliberately different model. The member is implemented *on the interface*, and it is only accessible through an interface-typed reference. Given `class C : I` where the default body lives on `I`, `new C().M()` does not compile unless `C` itself declares `M`; `((I)new C()).M()` does. The reasoning is that the default body is an implementation detail of the interface, not part of the class's public surface, and it keeps the class's API from silently growing when a library adds a default member. For an interviewer this is the sharpest contrast available: two mainstream languages shipped a feature under nearly the same name and made opposite calls about whether the member joins the implementing class's surface. Code and reviewers cannot carry intuitions from one to the other. ## Swift: static dispatch for non-requirements Swift's protocol extensions can supply implementations too, but dispatch depends on something subtle: whether the member is declared in the protocol body as a *requirement*. - Declared in the protocol and implemented in an extension as a default: dispatch is dynamic through the protocol witness table, so a conforming type's own implementation wins. - Declared *only* in the extension: there is no witness table entry, so the call is resolved statically. Through a protocol-typed value the extension body runs; through a concrete-typed value the type's own method runs. The same object answers differently depending on how you are holding it. This is the famous Swift gotcha, and it is directly relevant to evolution: adding a convenience to a protocol extension without also declaring it as a requirement means conforming types cannot meaningfully customise it, and any who tried get a split behaviour instead of an override. ## Go: do not widen; publish another interface Go has no default bodies, and adding a method to an interface breaks every type that must satisfy it. The idiomatic answer is structural rather than syntactic: keep interfaces one or two methods wide, and when new capability appears, publish a *new* interface and detect it at runtime. if wt, ok := src.(io.WriterTo); ok { return wt.WriteTo(dst) } // otherwise fall back to the generic copy loop That is exactly how `io.Copy` uses `io.WriterTo` and `io.ReaderFrom`, and how `net/http` exposes `Flusher` and `Hijacker` on a response writer. Old implementers are untouched, new capability is opt-in, and the fallback path defines behaviour for everyone else. Because Go interfaces are satisfied implicitly and are usually declared by the consumer, this pattern is cheap in a way it would not be in a nominal language. ## Rust: defaults plus the right to change your mind Rust trait methods may have default bodies, so adding one with a default is not a breaking change for implementers. The complementary trick is *sealing*: give the public trait a supertrait in a private module, so only your crate can implement it. That converts every future addition — default body or not — into a non-breaking change, at the cost of forbidding outside implementations entirely. It is the explicit version of a decision other languages make implicitly. ## How to choose Ask whether the new operation can be expressed in terms of existing members. If yes, a default body is the least disruptive route — but check your language's dispatch rule before assuming an implementer can override it, because Swift's answer for non-requirements and C#'s answer for class-typed references are both surprising. If no, or if the operation is genuinely optional capability rather than something every implementer should have, publish a second narrow interface and detect it, which is Go's default posture and a perfectly good one everywhere else. And if you are designing the abstraction today, keep it narrow and decide up front whether outsiders may implement it at all.