Parametric, subtype and ad-hoc polymorphism are usually listed as three flavours of one idea. What information does each of them actually use to choose an implementation, and why can some languages select an implementation from the return type while others cannot?

## Why the taxonomy exists "Polymorphism" means one name standing for many implementations. The classic classification (Strachey, refined by Cardelli and Wegner) splits it into *universal* polymorphism — one abstraction covering an unbounded family of types — and *ad-hoc* polymorphism — a finite set of separately written implementations that happen to share a name. Universal splits again into parametric and inclusion (subtype) polymorphism. The useful modern reading of the taxonomy is not the family tree but the question: **what information does the language use to pick the implementation, and when is that information available?** ## Subtype dispatch: one runtime value A virtual call inspects the receiver at run time and jumps to the implementation belonging to that object's class. Java, C++ (for `virtual` members), C#, Kotlin, Swift, Python, Ruby and Go all provide this, differing only in whether it is opt-in and whether conformance is declared or structural. The defining limitation is that dispatch needs an existing object. A factory, a parser, a "zero value", an empty collection — none of these have a receiver of the type you want, so subtype dispatch is structurally incapable of producing them polymorphically. ## Ad-hoc, form one: overloading Overload sets are resolved from the *static* types of the arguments. C++, Java, C# and Kotlin all do this at compile time; the runtime class of an argument is irrelevant. Two consequences worth naming: overloading is not a runtime mechanism at all, and it is not universal — Python and Ruby simply do not have it. In Python, defining a function twice rebinds the name; the first body becomes unreachable. Where Python wants type-directed behaviour it uses `functools.singledispatch`, which is genuinely runtime dispatch but only on the first positional argument, or it uses duck typing and lets the operation fail if the object lacks the method. ## Ad-hoc, form two: typeclasses, traits and protocols Haskell typeclasses, Rust traits, Swift protocols with associated types and Scala `given` instances resolve differently again: the compiler solves for an instance/impl using the whole inferred type of the expression, not just the arguments. The chosen instance is passed as a hidden dictionary (Haskell, and Rust for `dyn Trait`) or monomorphized in (Rust's static path). Because the solver sees the expected type of the result, **the return type participates in selection**: - Rust: `let n: i32 = "42".parse().unwrap();` and `let f: f64 = "42".parse().unwrap();` are the same call text choosing different impls. - Rust: `Default::default()`, `Vec::new()` plus inference, `T::from_str`. - Haskell: `read`, `mempty`, `minBound`, `fromInteger` — all keyed by what the context needs. ## Why return-type selection is the fault line Java and C# have subtype dispatch and overloading, so they cover argument-directed and receiver-directed choice, but they have no mechanism whose input is the expected result type. The workarounds are visible in every mainstream API: a distinct method name per target type (`Integer.parseInt` versus `Double.parseDouble`), or an explicit witness passed as an argument (`Class<T>`, a `TypeToken`, a `Supplier<T>`, a `Comparator<T>`) so the missing type information is smuggled in as a value. When you see a family of near-identical `parseX` methods, you are looking at a language without return-type-directed resolution. ## Parametric polymorphism: dispatch on nothing A parametric routine takes a type parameter it cannot examine. `identity`, `swap`, `reverse : List<T> -> List<T>` behave the same for every T because there is nothing type-specific to behave differently about. That is the point: the absence of dispatch is a guarantee to the caller, not a limitation. Bounded parameters ("T must be orderable") re-introduce exactly as much ad-hoc capability as the bound names, and no more — which is why bounds are usually expressed in the trait/typeclass vocabulary rather than the subtype one in Rust and Haskell, and why Go's type-parameter constraints are *type sets* (`~int | ~float64`) rather than interfaces when the operation is an operator that builtin types have no method for. ## Where the mainstream languages sit Java and C#: subtype plus overloading plus generics; no return-type-directed resolution. C++: subtype (opt-in), overloading, and templates whose bodies are checked structurally at instantiation, with C++20 concepts making the constraint declared. Rust: no inheritance at all, no overloading; traits carry the whole ad-hoc load, including return-type direction. Go: structurally satisfied interfaces for subtype dispatch, type-set constraints for parametric code, no overloading. Python and Ruby: everything is a runtime lookup, so the taxonomy collapses into duck typing. ## Interview framing Answer with the resolution input, not the definition: receiver value, static argument tuple, whole type environment, nothing. Then show you know the consequence — that only the third can pick an implementation before any value of that type exists.