proposal: spec: add comparable w/o interfaces

[Code-Hex]

What do I want?

• I want a new comparable type that does not include interface{}.

Background

#49584

• The current comparable type includes interface{}.
• If an interface{} is passed to the function, we need to determine if it is comparable at runtime using reflect package. (to avoid panic)
  • See examples

I think comparable type which can only be determined at runtime, is almost the same as any type.

generics

import "reflect"

func Equal[T comparable](v1, v2 T) bool {
	if !reflect.TypeOf(v1).Comparable() {
		return false
	}
	if !reflect.TypeOf(v2).Comparable() {
		return false
	}
	return v1 == v2
}

func main() {
	v1 := interface{}(func() {})
	v2 := interface{}(func() {})
	Equal(v1, v2)
}

non-generics

import "reflect"

func Equal(v1, v2 interface{}) bool {
	if !reflect.TypeOf(v1).Comparable() {
		return false
	}
	if !reflect.TypeOf(v2).Comparable() {
		return false
	}
	return v1 == v2
}

func main() {
	v1 := interface{}(func() {})
	v2 := interface{}(func() {})
	Equal(v1, v2)
}

[dsnet]

Wouldn't this need to exclude any interface type, not just interface{}?

All interfaces are considered comparable:

Interface values are comparable. Two interface values are equal if they have identical dynamic types and equal dynamic values or if both have value nil.

[AndrewHarrisSPU]

I feel like there's some really useful headroom where preferring the proposedEqualFunc over Equal: https://gotipplay.golang.org/p/GzTn8g4jz8N

This approach doesn't require reflection and does set the compiler up to be useful. It doesn't prohibit accidents with Equal, though.

[ianlancetaylor]

I believe that writing a generic function that uses the comparable constraint, and then instantiating that function using an interface type, is not going to be a common case. You've already shown how code can handle that case explicitly when it matters. It's not clear to me that this is important enough to require a language change.

[Code-Hex]

Thanks, everyone.

If a provider of a third-party package does some kind of validation using comparable, I think a provider needs to consider interface{}. However, I understand that this is not a common case.

I have noticed something while writing this proposal. I thought that the real problem was that Go not provide a type that could not be configured no matter how hard Go user tried.

For example, a comparable struct.

If this type is provided, users who have the same problem as I do will be able to write their own definitions. For example, let's call it comparablestruct.

type NonInterfaceComparable interface {
	constraints.Integer | constraints.Float | constraints.Complex | ~string | comparablestruct
}

What do you all think?

[syumai]

I've considered NonInterfaceComparable in the comment (#49587 (comment)).
To implement this idea, we would need not only comparablestruct, but also comparablearray.
Using this, the interface definition can be written as follows

type NonInterfaceComparable[T any] interface {
	~bool |
		constraints.Integer |
		constraints.Float |
		constraints.Complex |
		~string |   // String values
		~*T |       // Pointer values
		~chan T |   // Channel values
		~<-chan T | // Receive only channel values
		~chan<- T | // Send only channel values
		comparablestruct |
		comparablearray
}

To represent pointers and channels, this interface requires a type argument.

[rsc]

We should use the generics changes for a while before we decide we need two different kinds of comparable. I suggest we decline this and return in a few years if the need is still strongly felt.

[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

[rogpeppe]

@ianlancetaylor

I believe that writing a generic function that uses the comparable constraint, and then instantiating that function using an interface type, is not going to be a common case. You've already shown how code can handle that case explicitly when it matters. It's not clear to me that this is important enough to require a language change.

To address your second point first: it's not quite as simple as that. The code there can still panic when one argument is nil. Getting it right is more awkward and has more runtime overhead: https://gotipplay.golang.org/p/hJQ1TzxVeLl; in fact it's still not right.

With respect to your first point, I'm not so sure. One pattern that I've seen emerging multiple times so far in the generic Go code that I've written is that of hiding type parameters behind interfaces (sometimes known as "type erasure", I believe). This pattern makes it possible to take a value with type parameters and put it inside a heterogeneous collection such as a slice or map. Here's a simple example: https://gotipplay.golang.org/p/WgMcZIkVxPs .

In general, given a type T with type parameter P constrained by interface C, when C is usable as a non-constraint type, it seems to be possible to write a transformation from T[P] to T[C], and that's actually quite a useful property.

Unfortunately, when C contains a comparable constraint, we can't apply the above transformation because comparable isn't usable as a non-constraint type. It's possible to work around this by defining an auxiliary interface type, say C1, which contains all the methods of C but not the comparable constraint, then define C as:

type C interface {
     C1
     comparable
}

and then we can write a transformation from T[P] to T[C1] because values of type C1 satisfy the constraint C because all interfaces are comparable.

My initial thought when I first came across this this was that we should just make comparable usable as a regular interface value. After all, all interfaces are comparable, so adding a comparable element to an interface wouldn't change its semantics at all.

Then I realised that perhaps there's a more interesting potential semantic here that could be introduced without loss of backward compatibility: we could make a comparable constraint on an interface only admit types that are actually comparable. So comparing two interface types that both embed comparable would be guaranteed not to panic.

There are various places in the standard library that would probably have used this constraint if they could (for example the key value provided to context.WithValue), and it would provide a way of assuring that some particular type could always be compared without a panic, which is hard to do currently. The only straightforward way of doing so is to catch the resulting panic.

The only problem that I can see with allowing comparable to mean "always comparable without panic" within regular interface types is that comparable within a type parameter constraint does not mean that currently, because comparable as a type parameter constraint does allow regular interface values which might panic when compared.

I propose that we leave the above possibility open without committing to it by tightening the current type parameter proposal so that it does not consider interface types to be comparable. For example, this code would not compile:

func main() {
	fmt.Println(Equal[interface{}](1, "hello"))   // interface{} does not satisfy comparable
}

func Equal[T comparable](a, b T) bool {
	return a == b
}

If at some future date we allow comparable in regular interface types, you'd be able to write this instead:

	fmt.Println(Equal[comparable](1, "hello"))

With respect to this proposal, I'm suggesting that instead of adding a new kind of comparable type, we can change the existing comparable constraint to mean what it says, and that we restrict the current type parameters implementation so that we can do this in the future without breaking backward compatibility.

[Code-Hex]

@rogpeppe Thanks for the detailed explanation.

My motivation for this proposal was to question the possibility of including any in comparable. This is absolutely misleading.

This is an example of any can be passed to comparable.

https://gotipplay.golang.org/p/ukN96RW8Pui

I also often see code that returns an interface as a return value and does something with the result.

In this example, we return []bytes and string with some kind of interface{} (Here I'm using fmt.Stringer). We want to do comparisons within a function, so we specify comparable as a type parameter. The program is compiled. So we are convinced that it works, but in fact, it panics at runtime and terminates abnormally. I assume that a case similar to this will occur.

https://gotipplay.golang.org/p/f3LMqLbIRcx

---

I would be happy if comparable did not include any. Looking back at the process so far, it seems that there are several options.

1. Define a new comparable without any
2. Provide comparable for struct and array. And users can define comparable without any
3. Modify the existing comparable without any

if we choose the third option, I think this should be in time for the release of Generics. Because it's related to maintaining backward compatibility.