The sorting functions in the slices package are generally faster than their equivalents in the sort package. We've added doc comments to the sort package in 1.21 pointing at the faster equivalents, but for now did not modify their implementation. Issues like https://github.com/golang/go/issues/60777 show that there could be some rare scenarios where a change would introduce a regression.

In 1.22 we should consider forwarding the implementation of functions like sort.Ints to slices.Sort:

func Ints(x []int) {
  slices.Sort(x)
}

The following functions can be forwarded:

  • sort.Ints
  • sort.Strings
  • sort.Float64s (but we'll need to double check that the FP semantics align, e.g. NaN)
  • sort.IntsAreSorted
  • sort.StringsAreSorted
  • sort.Float64sAreSorted

The other functions in the sort package have slightly different semantics, so it may just be sufficient to retain comments suggesting to consider the slices package instead.

Comment From: rsc

sort.Float64s can call slices.Sort. We defined cmp.Compare the way we did specifically so that the two would match.

Comment From: gopherbot

Change https://go.dev/cl/508135 mentions this issue: sort: forward fixed-type slice sorting to slices package

Comment From: eliben

The attached CL is running into a bootstrapping issue, since the sort package is used in the Go compiler. Our current bootstrap version is 1.17 which doesn't even support generics. slices only makes it into the stdlib in 1.21, and the CL is making sort depend on slices.

According to https://github.com/golang/go/issues/54265 we plan to bump the bootstrap version to 1.20 in the 1.22 time frame.

Comment From: eliben

https://go.dev/cl/508135 was updated to work around the bootstrapping issue by using build constraints, per suggestions from @ianlancetaylor and @neild

Comment From: gopherbot

Change https://go.dev/cl/607315 mentions this issue: sort: drop implementation for Go <1.21