proposal: Go 2: noncompare keyword to make structs non comparable about go

[ianlancetaylor]

If we adopt #66408, we could add

package structs

type NonCompare [0]func()

I think this is a very rare need. I don't see any need for a new keyword here.

[lucastomic]

I agree that that code you shared may be difficult to understand without the comment. However, I am not sure that it is necessary to change the syntax of the language, since a simpler version of the code can be achieved using composition

type MyStruct struct {
	val int
	NotComparable
}

type NotComparable struct {
	_ []int
}

func main() {
	a := MyStruct{val: 1}
	b := MyStruct{val: 1}
	fmt.Println(a == b) //compilation error
}

[earthboundkid]

Zero length elements should go first in the struct to prevent unnecessary padding:

type UniqueByte struct {
	NotComparable
	value byte
}

Output:
0
8
2
1

[bjorndm]

This is actually pretty common since the Go protobuf code uses this kind of pseudo directives: https://github.com/protocolbuffers/protobuf-go/blob/master/internal/pragma/pragma.go But, #66408 is likely the correct solution.

[Chig-Beef]

That's a nice one, I do like that and just reading it I think it's pretty understandable. It still just feels like the language is slightly punishing you by being obtuse, which in most cases is the right thing to do, but marking things as non-comparable is completely valid. Also, using _ []int or _ [0]func() isn't a noop in terms of memory.

package main

import (
	"fmt"
	"unsafe"
)

type NotComparable struct {
	_ [0]func()
}

type UniqueByte struct {
	value byte
	NotComparable
}

type UniqueByteComp struct {
	value byte
	dummy byte
}

func main() {
	fmt.Println(unsafe.Sizeof(NotComparable{}))
	fmt.Println(unsafe.Sizeof(UniqueByte{}))
	fmt.Println(unsafe.Sizeof(UniqueByteComp{}))
	fmt.Println(unsafe.Sizeof(byte(0)))
}
/*
Output:
0
16
2
1
*/

Although it looks like that on its own the NotComparable type has no effects on memory by itself, it does start to show. Using _ []int also takes up more memory than _ [0]func(). Since whether something can be compared or not is governed by its type, it should be possible to deal with non-comparable variables at compile time, just as it is with slices. 14 bytes isn't much, but I get concerned with having larger slices of non-comparable items and then dealing with gc? I also don't know the effects on time performance, but if it's having to allocate that little extra memory it's definitely non-zero, which I usually wouldn't have an issue with but in this case it's unnecessary.

[Chig-Beef]

That's cool, does that work with multiple "flags," say we had use for more things like this, if I had 3 at the top, would the logic work for all 3 or just the top one? There is still extra (although yes, not much) redundant memory being created here.

fmt.Println(unsafe.Sizeof([32_768]UniqueByte{}))
fmt.Println(unsafe.Sizeof([32_768]UniqueByteComp{}))

/*
Output:
262144
65536
*/

I don't think a new keyword would be a good option though, I can definitely see why people don't want that. Is there are a better way to implement this? Or is it too little gain for such a large change? Especially if it breaks compatibility.

[Chig-Beef]

That's probably the best way we could be doing it with what we have now and from what I saw in the issue it look like you can add a lot of "flags" in there.
The main issue I originally had was readability, and I think for the most part this fixes it because you don't see the [0]func() until you go looking for it, at which point you're probably ready to learn what it means.
My last issue would be this

type UniqueByte struct {
	structs.NonCompare
	value byte
}

f := UniqueByte{0}

Which results in an error. With the current solutions you can't create a struct this way (without specifying fields), because it still treats the flag as a property (because it is).

I don't mind that too much though, because I do like specifying the field names, unless it's a small struct (like an x, y, z position).

Also the fact that order of property definitions affects the size of a struct in memory seems crazy to me, but I think I might be thinking too hard about it (':

[ianlancetaylor]

Based on the discussion and the emoji voting, this is a likely decline. Leaving open for three weeks for final comments.
— ianlancetaylor for the language proposal review group