Slices, Maps and Ordering

container/heap.Interface embeds sort.Interface, so your type needs Len, Less and Swap, plus Push(x any) to append one element and Pop() any to remove and return the last one. Five methods, and you own the storage.

Go deliberately randomises map iteration, so no order is guaranteed or repeatable. For stable output, copy the keys into a slice, sort that slice, then read the map in that key order.

slices.Clone allocates a new backing array and copies the elements into it, so the two slices no longer share storage. Plain assignment copies only the slice header, leaving both names pointing at one array.

slices.Sort reorders a slice in place into ascending order and returns nothing. It is generic over element types that support the less-than operator - integers, floats and strings - so no comparison callback or interface implementation is needed.

Go's sort.Interface requires three methods: Len() int returns the number of elements, Less(i, j int) bool reports whether the element at index i must sort before the one at index j, and Swap(i, j int) exchanges those two elements.

Compare one key at a time: if the primary fields differ, return that comparison; otherwise fall through to the next field, and end with a unique tie-breaker. Never join key comparisons with || or &&, which produces an inconsistent ordering.

sort.Slice takes the slice plus a less closure, so you skip declaring a named type with Len, Less and Swap. The cost: it accepts any, so a non-slice argument panics at run time instead of failing to compile, and it is not stable — sort.SliceStable is.

cmp.Compare treats a NaN as smaller than every non-NaN value, so NaNs come first, and reports two NaNs as equal by returning 0. Negative and positive zero also compare equal, giving a total order.

cmp.Or returns the first argument that is not the zero value of its type, or the zero value if none is. It is an ordinary call, so every argument is evaluated first: no short-circuiting.

Your Pop method only detaches the last slice element and knows nothing about ordering. heap.Pop swaps the root to the end, sifts the heap back into shape, and only then calls your method, so only heap.Pop yields the smallest item.

Push and Pop change the queue's length. A value receiver would append to a copy of the slice header, so both assign back through the pointer — which means only the pointer type satisfies heap.Interface.

The slice was filled by ranging the map, so its starting order is random, and sorting only by count leaves equal counts in that random order. Fix it by making the comparison a total order: break ties on the key.

slices.Delete shifts the later elements left inside the same backing array and returns a shorter header, so a variable you never reassign still shows the old length. Since Go 1.22 it also zeroes the slots it vacates.

slices.Equal compares length and then elements, and both slices have length zero with no elements. reflect.DeepEqual adds a rule that two slices must be both nil or both non-nil, so it reports them as different.

It is the insertion point: the position the target would occupy if it were placed in the sorted slice. It ranges from 0 to len(s) inclusive, so it can be one past the last element and must be range-checked before indexing.

slices.SortFunc's callback returns a negative, zero or positive int meaning a sorts before, equal to, or after b. The three-way result reports equality, which a boolean less-than cannot, so one function can also drive stable sorting and binary search.

sort.Reverse returns a new sort.Interface that wraps yours and calls your Less with its two arguments swapped. It only flips the ordering — it moves nothing until you pass it to sort.Sort or sort.Stable.

Returning 0 for NaN pairs claims a NaN equals every score, so two differing scores both equal it. Equality is no longer transitive, the comparison is not a valid ordering, and the result depends on input order.

Every place the emitter ranges a map is a source of randomised order. Sort the keys at each emission site, or keep the schema's order in slices and use maps only for lookup, then assert byte-identical output by generating twice in one test.

Binary search assumes the slice is sorted by the comparison it is given. Data ordered by a different key makes it halve the wrong way and return a plausible index with no error. Assert sortedness, and test against a linear scan.

The ordering stops being consistent: no pair is ever recognised as equal, so the resulting order is arbitrary, sort.Stable can no longer preserve input order, and sort.IsSorted may report false on the sort's own output. Nothing is lost — the sort only swaps.

The fmt package sorts a map's keys itself before printing, so its output is stable. The map is still unordered; ranging over it directly gives a randomised order. encoding/json sorts map keys when marshalling for the same reason.

container/heap tracks no positions, so heap.Fix trusts the index you pass it. If Swap does not write each element's new position into its index field, that field goes stale after the first sift and Fix repairs the wrong slot.

maps.Clone and slices.Clone copy one level only, so nested slices and maps in the copy still share storage with the observed snapshot. Mutating the copy edits the snapshot too, and the desired-versus-observed diff comes out wrong on every tick.

sort.Search(n, f) returns the smallest index i in the range 0 to n-1 where f(i) is true, and returns n when none is. The predicate must be false for a prefix of that range and true for the rest.

Make the comparator-taking function the primitive and add a cmp.Ordered-constrained wrapper on top. Adding an exported function later is compatible; changing one's parameters is not, so commit to the shape that excludes nobody.