Some languages model a callback as a one-method interface, while others have first-class function types. Compare the two encodings and explain what each one makes possible that the other does not.

## Two encodings of the same idea "Pass behaviour as a value" can be typed in two ways. **Nominal (single-abstract-method type).** You declare a named type with exactly one abstract operation, and a value of that type is a piece of behaviour. Java's functional interfaces work this way, as do C# delegates. The type has an identity beyond its shape: a name, documentation, possibly extra default helper methods, and the ability to participate in overload resolution. **Structural (function type).** The language has a type constructor for functions — Kotlin's `(A) -> B`, Go's `func(A) B`, Swift's `(A) -> B`, TypeScript's `(a: A) => B` — and any function with the right parameter and return types is a value of it. Nothing is declared. ## What the nominal encoding buys **Meaning.** A Java `Comparator<T>` is not just "a function from two Ts to an int". Its documentation carries a contract: total ordering, consistency, antisymmetry. Sorted collections rely on it. A bare function type has nowhere to hang that requirement, which is why even languages with real function types keep named single-method types for contracts whose semantics exceed their signature. **Extra members.** Because a functional interface is still an interface, it can carry default methods: `Comparator.thenComparing`, `Predicate.and`, `Function.andThen`. The combinators live on the type. In a structural function-type language they must be free functions or extension functions instead — Kotlin puts them in the standard library as extensions on function types. **Overload identity.** Two methods can accept differently named single-method types with the same shape and be distinguishable. With structural function types they collide. ## What the structural encoding buys **Interchangeability.** In Kotlin, a `(String) -> Int` produced anywhere is accepted anywhere that type is expected, with no adapter. In Java, a value of `interface Task { void run(); }` is not a `Runnable` even though the shapes are identical; you must re-wrap it as `r::run`. That friction is the whole reason `java.util.function` exists as a large fixed vocabulary that everyone is expected to reuse. **No boxing gymnastics from erasure.** Because Java's function-like types are ordinary generic interfaces and generics erase to references, `Predicate<Integer>` boxes; the JDK therefore ships hand-written specialisations `IntPredicate`, `LongFunction`, `DoubleUnaryOperator`, and so on. A language with a real function type still has to decide about specialisation, but the API surface does not fan out into dozens of near-duplicate named types. **Composition without ceremony.** Higher-order code — a function returning a function returning a function — types naturally, whereas nominal encodings need a named type per arity and shape. ## The middle ground and its seams Kotlin has both, and the seam is instructive. Function types are the native encoding; `fun interface` was added so a lambda can be converted to a Java-facing SAM type when calling into Java libraries. The conversion is explicit at the call site precisely because the two are not the same thing. C# sits in the nominal camp with a twist: `Action` and `Func<...>` are named delegate types, so nominally they are as rigid as Java's interfaces — but the language special-cases conversion between compatible delegate types, and delegates are **multicast**, meaning several handlers can be combined into one delegate value and invoked together. That capability has no equivalent in a SAM interface, which is why C# events are built on it. Go has both and keeps them separate on purpose: a `func(T) error` is used when the behaviour is all that matters, and a one-method interface is used when the receiver carries state or identity the caller may want to inspect or type-assert on. `http.HandlerFunc` is the bridge — a named function type with a method, so a plain function satisfies the `http.Handler` interface. ## Choosing - Use a **named single-method type** when the contract's meaning exceeds its signature (ordering, retry policy, comparison semantics), when you want combinators to hang off it, or when two same-shaped parameters must be distinguishable in overloads. - Use a **function type** when the shape is the whole contract, when values will be composed and passed through many layers, or when you are writing generic higher-order code. - In an API crossing language boundaries, remember that the nominal side cannot accept the structural side without a wrapper, so publish the named type and let callers convert once at the edge.