proposal: Go 2: add spaceship operator <=>

[ianlancetaylor]

It's moderately common in any programming language to write code like (from compress/bzip2/huffman.go):

	if pairs[i].length < pairs[j].length {
		return true
	}
	if pairs[i].length > pairs[j].length {
		return false
	}

Perl has a special operator for this kind of code: <=>, known as the spaceship operator. The spaceship operator is also available in C++20, Ruby, and PHP.

In Go, the new operator <=> would be permitted for any two values a and b. It would follow the same type rules as for any ordered comparison. The expression a <=> b would evaluate to an untyped integer value. The value would be -1 if a < b, 1 if a > b, and 0 if a == b. For code like the above it would be used as

	if cmp := pairs[i].length <=> pairs[j].length; cmp < 0 {
		return true
	} else if cmp > 0 {
		return false
	}

or as

	switch pairs[i].length <=> pairs[j].length {
	case -1:
		return true
	case 1:
		return false
	}

The operator lets code capture all aspects of a comparison in a single expression. The cost is that in the typical case additional comparisons are required to use the result, but those additional comparisons are simpler, and the code is easier to read because there is no need to verify that the different comparisons are using exactly the same values.

[seebs]

lessThan, greaterThan := a <=> b
if lt, gt := pairs[i].length < pairs[j].length; lt {
  return true
} else if gt {
  return false
}
// they're equal

// or alternatively:
switch { // implicit-true
case lt: return true
case gt: return false
}
// they're equal

I suggest this because, while I actually find the thing where true and false aren't numeric values and can't be |d together somewhat frustrating at times, I think it also makes for clearer code.

Alternatively:

lessThan, greaterThan := a <> b
lessThan, equalTo, greaterThan := a <=> b

[robpike]

Isn't this sort of thing what the years of work on parametric types is supposed to solve? :)

[seh]

Why mandate that the nonzero return values be -1 or 1, as opposed to just negative or positive respectively? With the latter approach, <=> implementations can use subtraction.

[atdiar]

The most straightforward version without the operator is much easier to understand for me.
Just a data point.

Probably stems from the fact that it uses regular mathematical operators.

It seems harder to human-parse the version with the spaceship operator.

A generic comparison function if can be defined would be better.

[seebs]

I actually sort of like <> as a less-than-greater-than operator, and i know roughly what it means.

if this didn't exist, and i showed someone a program using it, and they otherwise knew Go, i don't think they'd be confused by it.

i was also tempted at one point by proposing something like a , ok form for comparison operators, but if you change the semantics of the existing operators, you have broken code probably.

oh, and i think the reason to mandate -1/1 is so you can switch on them. (and now i want to be able to use -1 as an index into a thing, but i see problems here.)

if you did it with arbitrary ranges, the switch would be:

switch {
case cmp < 0:
case cmp > 0:
}

but at that point, you might as well just write

switch {
case a < b:
case b > a:
}

and i just realized that's wrong and i'm leaving the error here to point out: yes, the spaceship operator DOES prevent mistakes actual programmers can make even while thinking about the problem.

[cespare]

@seebs <> is used in SQL to mean !=.

[sbinet]

as syntax is always a bit contentious, I'd propose to recognize that fact as a primordial law of human nature and call it a tie.

actually, make that the tie starship: |=|.

(an improved version of gopls could also add some extra FX, playing the sound[1] of a TIE fighter as soon as such a symbol would appear on your favorite editor. adding extra harmonics for each extra TIE operator appearing.)

• [1] https://www.youtube.com/watch?v=izZm4oYpLCc

[Integralist]

I'm not sure if the example given is the most common use case, because if it is then I think for the sake of one line of code (the original was 6 loc the new operator version is 5 loc) the code clarity is reduced for not much benefit. I personally much prefer the current go implementation with explicit conditional blocks.

[martisch]

One upside I can see to an explicit <=> is that it is much easier for e.g. the Go GC compiler to recognise and optimize for then trying to figure out if a switch or if else chain is optimizeable (and keeping observable side effects). A simple case that can be replaced would be and it could just be made a direct function call to the runtime internal cmpstring:

go/src/strings/compare.go

Line 13 in 0e85fd7

func Compare(a, b string) int {

[atdiar]

Is time.Time at least partially ordered if we take into account timezones?
Because it just hit me that I didn't pay attention to this... 🙃

[yiyus]

What advantage does the proposed solution offer with respect to:

if cmp := pairs[i].length - pairs[j].length; cmp < 0 {
	return true
} else if cmp > 0 {
	return false
}

?