proposal: x/exp/slices: add Sorted

[AMRALAA10]

It would be great to have a sorted, generic function similar to Sort but instead of sorting in place it returns a new sorted array.

func Sorted[E constraints.Ordered](x []E) []E

Usage:

// Instead of doing this
a := []int{ 7, 4, 6, 2, 9}
b := make([]int, len(a))
copy(b, a)
slices.Sort(b)

// do this
a := []int{ 7, 4, 6, 2, 9}
b := slices.Sorted(a)

In my opinion the second approach is cleaner, more readable and easier to understand.

[seankhliao]

original would be

b := slices.Clone(a)
slices.Sort(b)

imo this is clear enough

[randall77]

Sorted is a bit too close to sort.IsSorted, which has a different meaning.

[AMRALAA10]

The name Sorted is inspired from python sorted function. it would be intuitive to many developers and they can guess what it does.

[AMRALAA10]

original would be

b := slices.Clone(a)
slices.Sort(b)

imo this is clear enough

One line is clearer and more flixable than 3. consider this:

// instead of
a := functionReturnsArray()
slices.Sort(a)
passToFunction(a)

// can be reduced to 
 passToFunction(slices.Sorted(functionReturnsArray()))

[AMRALAA10]

Another common scenario.
You want to compare 2 arrays without changing their order.

a_clone := slices.Clone(a)
b_clone := slices.Clone(b)

slices.Sort(a_clone)
slices.Sort(b_clone)

diff := cmp.Diff(a_clone, b_clone)

with Sorted

diff := cmp.Diff(slices.Sorted(a), slices.Sorted(b))

Think also if you want to compare more than 2.

[AMRALAA10]

Seems like folks don't need this feature.

[ianlancetaylor]

You can retract the proposal if you like, but note that the proposal process takes weeks even at its fastest. This proposal hadn't even made it to the committee. There are hundreds of proposals in the backlog, unfortunately; see https://github.com/orgs/golang/projects/17.

But I agree that the emoji voting on this proposal is not in favor.

[AMRALAA10]

Will keep this open for now to give it complete shot, and the committee can decide.

[rsc]

No one is arguing that slices.Sorted is not useful. The main problem from a Go API design standpoint is that it hides an allocation that the user has no control over, which makes programs that use slices.Sorted generate more garbage than they might otherwise appear to. In contrast, if you write slices.Clone first, then it's more obvious what is going on.

[AMRALAA10]

Perfect, Thank you for explaining your point of view, Always appreciate a proper discussion :).

It is a good point and I agree with it, But also I don't think a function shouldn't be implemented just because it might not be obvious for some user, We could come up with better ways to make it obvious for them that this function allocates an extra space, those ways could be name changing, comments on the function, highlighting it on the docs, .. etc.

[icholy]

The function could be called SortClone or CloneAndSort to make the allocation more obvious. You'd need to make a case that this comes up often enough to warrant a new function.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[rsc]

No change in consensus, so declined.
— rsc for the proposal review group