When both a bound and an unbound interpretation of a `::method` reference could satisfy the expected type, how does Kotlin resolve it, and where can ambiguity or surprises arise?

## The two forms are syntactically distinct `instance::method` (bound) and `Type::method` (unbound) differ by what is on the left. So there is no ambiguity about bound-vs-unbound *per se* — you choose by writing a value or a type. Ambiguity instead comes from **which member** the name resolves to and **which function type** is expected. ## Expected-type-driven resolution A callable reference is resolved against the **expected type** of the context. The compiler enumerates candidate callables for the name, computes each candidate's reference type (applying the +1 receiver rule for unbound), and keeps those assignable to the expected type. ```kotlin class P { fun f(x: Int) = x; fun f(x: String) = x.length } val g: (P, Int) -> Int = P::f // picks the Int overload by expected type val h: (P, String) -> Int = P::f // picks the String overload ``` Here the expected type disambiguates overloaded `f` for the unbound reference. ## Ambiguity cases ### 1. Multiple fitting overloads If two overloads both match the expected type, you get an ambiguity error and must cast or use a lambda: ```kotlin // val r = P::f // error if expected type is too loose val r = P::f as (P, Int) -> Int // explicit ``` ### 2. Member vs extension A name available as both a member and an extension on the same type can be ambiguous; qualify or use a lambda `{ it.method() }`. ### 3. Companion-object name collision When a class has a companion, `Foo::bar` may resolve to an unbound member of `Foo` or a member of the companion object (which is itself a bound-like reference to the singleton). Use `Foo.Companion::bar` to be explicit. ```kotlin class Foo { fun bar() = 1; companion object { fun bar() = 2 } } val a = Foo::bar // unbound member: (Foo) -> Int val b = Foo.Companion::bar // bound to the companion: () -> Int ``` ### 4. SAM / Java interop When the target is a Java functional interface, SAM conversion plus the receiver-arity rule can change which form fits; being explicit with the expected type avoids surprises. ## Practical guidance - Prefer assigning the reference to a variable with an explicit function type, or pass it into a slot with a known type, so resolution is deterministic. - For overload ambiguity, the cleanest fixes are an explicit type annotation, an `as` cast, or a lambda that names the call. - Remember the unbound arity (+1 receiver) when matching against the expected type — it is the most common source of a confusing mismatch. ## Why this is a principal-level concern API authors deciding whether to expose methods that are commonly passed as references should keep overload sets reference-friendly (avoid overloads that collide under the +1 rule) and document whether bound or unbound usage is intended, because the ergonomics of `map(Type::m)` vs `op(instance::m)` depend on it.