What does sort.Reverse do to a sort.Interface, and why is it not the same as reversing the slice?

## What the wrapper is `sort.Reverse(data Interface) Interface` does not sort, reverse, or copy anything. It returns a value that **embeds** the `sort.Interface` you gave it and replaces a single method. Written out, it is equivalent to: ```go type flipped struct{ sort.Interface } func (f flipped) Less(i, j int) bool { return f.Interface.Less(j, i) } ``` Embedding promotes `Len` and `Swap` unchanged, so the wrapper counts and moves exactly the same elements as the original; only the question "does `i` come before `j`?" is asked backwards. This is a small, instructive piece of the standard library: it shows interface embedding used to override one method of an existing implementation without knowing the concrete type behind it. Because it returns an interface value and does no work, the wrapper is inert on its own: ```go sort.Reverse(byScore(rows)) // does nothing at all sort.Sort(sort.Reverse(byScore(rows))) // sorts descending sort.Stable(sort.Reverse(byScore(rows))) // same, ties keep input order ``` A reviewer sees the first line about once a year, and it is always a bug. ## Flipping is not reversing "Reverse the ordering" and "reverse the slice" are different operations, and they only coincide when the data is already sorted ascending with no ties. Wrapping and sorting asks the algorithm to build a descending order from wherever the elements currently are; physically reversing a slice mirrors its current arrangement, whatever that is. If the input is unsorted, mirroring it gives you nothing useful. ## It flips every key This is the trap worth remembering. A multi-key `Less` might rank by score ascending and then by name ascending. Wrap it and you get score **descending** and name **descending** — the tie-breaker is reversed too, because the wrapper knows nothing about your keys and simply asks the whole comparison backwards. So a common ranked-report requirement — highest score first, alphabetical within a tie — cannot be expressed by wrapping at all. It has to be written into the comparison cascade directly, with `>` on the score and `<` on the name: ```go func (r byRank) Less(i, j int) bool { a, b := r[i], r[j] if a.Score != b.Score { return a.Score > b.Score // descending } return a.Name < b.Name // ascending within a tie } ``` The rule of thumb: `sort.Reverse` is right when the ordering is one-dimensional or when *every* key genuinely reverses together; anything mixed belongs inside `Less`. ## Stability under the wrapper A reasonable worry is whether wrapping destroys `sort.Stable`'s guarantee. It does not. Two elements are equal when the comparison is false in both directions, and swapping the arguments of a symmetric-false pair leaves it symmetric-false: equals under the original `Less` are exactly the equals under the flipped one. So `sort.Stable(sort.Reverse(data))` still preserves the input order of tied elements. What changes is only which non-equal pairs are ordered which way. ## Where it shines The wrapper's real value is that it composes with orderings you did not write. Given a package that exports a `sort.Interface` for its own type, or the standard adapters `sort.IntSlice`, `sort.StringSlice` and `sort.Float64Slice`, you get the descending sort for free: ```go sort.Sort(sort.Reverse(sort.IntSlice(nums))) ``` No second type, no duplicated comparison logic, and no risk of the ascending and descending versions drifting apart — which is exactly what happens when a codebase grows a `byScore` and a `byScoreDesc` side by side and only one of them gets the new tie-breaker. ## Checking your work `sort.IsSorted(sort.Reverse(data))` reports whether the data is in the reversed order, which is a tidy assertion in a test: build the wrapper once, sort through it, then ask the same wrapper whether the result satisfies it.