What does sort.Slice give you over implementing sort.Interface, and what does it cost?

## What it is ```go func Slice(x any, less func(i, j int) bool) func SliceStable(x any, less func(i, j int) bool) func SliceIsSorted(x any, less func(i, j int) bool) bool ``` All three take the slice itself plus one closure. Compared with implementing `sort.Interface`, you supply only the ordering: ```go sort.Slice(rows, func(i, j int) bool { if rows[i].Score != rows[j].Score { return rows[i].Score > rows[j].Score } return rows[i].ID < rows[j].ID }) ``` No named type, no `Len`, no `Swap`. For an ordering used once, in one function, this is the shorter and clearer form, and it is why most everyday Go sorts are written this way. ## How it fills in the missing methods `Len` is trivial — the package takes the slice's length by reflection once. `Swap` is the interesting one: `sort.Slice` calls `reflect.Swapper(x)`, which returns a `func(i, j int)` specialised to that slice's element type. The reflection work happens **once**, when the sort starts; the returned function then swaps by moving bytes, so the per-swap cost is an indirect call rather than a reflective operation. The same is true of `less`: it is an ordinary function value called indirectly. In practice a `sort.Slice` call and an equivalent `sort.Interface` implementation are in the same performance neighbourhood; neither inlines the comparison, and if a benchmark says the ordering is your bottleneck, the fix is usually a cheaper key rather than a different API. ## The costs **Run-time typing.** The first parameter is `any`. Pass something that is not a slice — a map, an array, a pointer to a slice, a `nil` interface — and the call **panics at run time**. The compiler cannot help you. This is the price of a pre-generics API that must accept every slice type. **The closure gets indices, not elements.** `less(i, j int)` receives positions in the slice *as it currently is*, mid-sort, after arbitrary swaps. The closure must therefore index the slice it closes over. Capturing element values beforehand is a real bug: ```go // WRONG: keys never move, but the elements do keys := make([]int, len(rows)) for i, r := range rows { keys[i] = r.Score } sort.Slice(rows, func(i, j int) bool { return keys[i] < keys[j] }) ``` After the first swap, `keys[i]` no longer describes `rows[i]`, and the result is nonsense. Precomputed keys have to live *inside* the elements being swapped — add a field to the struct, or sort a slice of `{key, row}` pairs — so that swapping moves the key with its row. **No name for the ordering.** A closure cannot be reused, documented, or tested on its own the way a `type byRank []Row` with a `Less` method can. When the same ranking is applied in three places, three closures drift apart; a named type gives the ordering an identity, and a `Less` method can be unit-tested pair by pair. ## Stability `sort.Slice` makes **no guarantee** about elements the closure reports as equal — they may end up in any relative order. `sort.SliceStable` keeps them in their input order. The same split exists for the interface-based API: `sort.Sort` versus `sort.Stable`. Choosing the stable variant is a decision about the *output*, not about performance folklore: if your ordering has a unique final tie-breaker, no elements are ever equal and the two behave identically. ## Which to reach for A reasonable default: use `sort.Slice` for a local, one-off ordering inside a single function, and implement `sort.Interface` when the ordering is part of a package's vocabulary, when it must be reused or reversed by name, when it must be unit-tested independently, or when the thing being sorted is not a plain slice at all — parallel slices, a struct wrapping a slice, or any container that can only expose count, compare and swap.