proposal: make array types ordered when their element type is ordered

[martisch]

According to the Go spec array types are comparable but not ordered. Which is odd for e.g. [...]byte array values since strings are ordered and comparable.

As arrays values dont have a capacity and the same number of elements for the same type the problems of having multiple ways to consistently define an ordering or comparable with or without taking capacity into account such as for slices is not the case for arrays types. (#38377, #23725)

I propose to make array types ordered if their element types are ordered so it is possible to use comparison operators like < on two array values.

Semantics

Array values are ordered if values of the array element type are ordered.
An array a is less than an array b if there exists and index i with a[i] < b[i] and there is no index j with j < i and a[i] != b[i].

Note: This does not require the array element values to be sorted. Just for the type of the elements having a defined sort ordering according to the Go specification. e.g. int, uint8, float64... . Arrays of type [2]bool or [3]interface{}wont be orderable.

Examples

func lessVector(a,b [16]byte) bool {
  return a < b
}

Or to avoid a copy:

func lessVector(a,b *[16]byte) bool {
  return *a < *b
}

For the above the compiler could then optimise this to an inlined 128bit comparison on e.g. amd64.

What are the current alternatives that work and have the same semantics?

For byte arrays we have:

func lessVector(a,b [16]byte) bool {
  return string(a[:]) < string(b[:])
}

func lessVector(a,b [16]byte) bool {
  return bytes.Compare(a[:], b[:]) < 0
}

Others array types need a manually crafted function looping over the elements for each type.

Motivation

This came up when writing a function that finds a minimum from a slice of array values efficiently. For [16]byte array values one can use string conversions to tap into the compilers optimisation for comparing known length byte sequences. The Go Gc compiler inlines known length short string comparisons. This currently doesn't work for string(a[:]) < string(b[:]) but could be detected by the compiler. It however instead be better if the code was more concise and had the same optimisations applied to e.g. [8]uint which cant use the string conversion pattern.

Complexity and Overhead

Go code that doesn't use array ordering wont be affected as this proposal is backwards compatible and doesn't add runtime overhead for other array operations. A new spec compatible Go Compiler would need an adjustment of the type checker and compiler.

In contrast this can avoid complexity by adding a concise expressible way to order two large memory regions in form of arrays thats easy to detect and optimise vectorised by the compiler instead of trying to detect a for loop that does element wise comparison.

The computational work done for array comparison is similar to string comparisons or to already allowed array equality checks. Therefore the work involved in a simple operator such as < should not be surprisingly large for a Go programer already using strings and arrays.

A minimal implementation could implement one generic array compare runtime function similar to the generic runtime hashing function that is used with compiler generated calls:

go/src/runtime/alg.go

Line 163 in b05b254

func typehash(t *_type, p unsafe.Pointer, h uintptr) uintptr {

A compiler could then specialise functions for some types and inline and optimise small array compares to avoid using a generic function as an optimisation.

Alternatives

Go users can write out their compare function as currently and the go compiler can detect such a loop and optimise matching ones for some types like uint/byte/... to inlined memory compares.

This would be a special case of a potential general future autovectorisation optimization.
Upsides:

• does not require a language change
• keeps the language consistent in that neither arrays, slices or structs support ordering
• no need to support e.g. floats or complex that have NaNs in the implementation
• leaves the possibility open for a future language change when more evidence can be collected based on vectorisation optimization if this case is used often enough

Other considerations

In context of the addition of generics this likely also allow array types to be used in containers/functions that expect the passed in type to be ordered. On the otherside generics will
even make it easier to write a generic array compare function (based on converting to slices first).

[mvdan]

I think this is reasonable - having to convert a byte array to a slice, and then to a string, is unfortunate even if the compiler knows to optimize those away.

I'm curious to understand why you want to draw the line at arrays, though. The proposal makes [...]byte or [...]int ordered, and one can still convert []byte or []rune to string to use < on them. But other slice types like []int16 or []float32 are left without a good way to use <. With this proposal one could somehow copy the contents into an array, but that feels wrong.

That is, why not allow slice values to be ordered when their element type is also ordered, just like you propose for arrays?

[martisch]

Ordering is a property of values of the same type. The type of a []byte slice with capacity 16 or 17 is the same even if the length is 16. However when ordering these two different slices of same type its unclear if capacity and values past the length should be part of the ordering or not. See for previous discussions on this in #38377 which already needs to be considered for equality. Strings dont have the same problem since they have more semantical context in which they are used and no capacity.

I dont think this proposal further restricts the possible ways slice equality could be defined as array equality is already defined. It may restrict the ways in which a consistent slice ordering could be defined for the subset of slice values with same length and capacity. However I do not think the ordering proposed for these is controversial as the string ordering already also is consistent with the proposal here.

[jimmyfrasche]

What about structs?

[bcmills]

@jimmyfrasche, that seems like a matter for a separate proposal.

[martisch]

I intenionally left out structs as they would have their own additional complications to discuss: ordering of fields (future go versions might pack them differently in order into memory), blank fields... (not saying discussions on these might be controversial but its a broader discussion than this proposal) and I wanted to avoid getting making ordering for arrays work defocused by how it would work for structs.

On the implementation side I expect supporting array ordering to be much simpler than arbitrary structs. So there might be some new per type alg functions necessesary for structs like we have for equality.

[ianlancetaylor]

For an array of a floating point type, I'm not sure how NaN values should be handled. For a single floating point value, a comparison involving NaN always evaluates to false. Does this mean that we should simply ignore any array elements where either side of the comparison is NaN? And if there is NaN at every index the comparison evaluates to false? What do other languages do? Or am I just missing something obvious?