Repository navigation
spec: document definition of comparable #50791
Description
Activity
What would it be an alias of?
At the moment we have the equivalent of
type comparable <magic_comparable_interface_literal>
in the universe scope.
If it were an alias, it would be the same but as an alias declaration.As it is now, there is an underlying type, which is that magic interface which doesn't have a name and can't be printed correctly.
I can't think of a way to make the distinction visible inside Go at the moment, but it's visible through the
go/typesAPI: This code prints the underlying type ofcomparable. Because there's no proper literal for it, it printsinterface{}which is misleading at best. The actual underlying type behaves correctly (test).If we make
comparablean alias for this magic interface literal, the underlying type would be itself and could be printed ascomparable.Perhaps it should be a "basic" type like
int, etc.I'm confused about why making it an alias would change the underlying type, but perhaps my understanding that point that doesn't matter. Totally agree about it being its own underlying type. Calling it a 'basic' type would work too.
Agree about it being its own underlying type, which means it can't be a defined type. I think making it a basic type (like unsafe.Pointer) could be problematic. We'd have to introduce a new
BasicKind, which behaves rather differently than all other basic kinds. This would require a updating a lot of code in tools.Making
comparablean alias for "the magic comparable interface" makes sense to me. Similar toany, we'd have special handling for formatting "the magic comparable interface" ascomparable, but unlikeanywe don't have to implement this via pointer tracking: we have a bit onInterfacethat tells us if it iscomparable.Ok, we all agree thatcomparable's underlying type is itself.Need to mention this in the spec in the section on underlying types, and need to adjust implementation accordingly.
See conclusion.
- changed the title
[-]spec: should `comparable` be an alias type (like `any`)[/-][+]spec: document that `comparable` is its own underlying type[/+]on Jan 25, 2022 Change https://golang.org/cl/380754 mentions this issue:
go/types, types2: underlying type of comparable is itselfIf we ever permit variables to have type
comparable, we'll have to explain what happens if you callreflect.TypeOfon a pointer to such a variable. Presumably thereflect.Kindwill beInterface, because it is, after all, an interface type. For thatreflect.Type, it seems to me that theNamemethod should return"comparable". That is what happens with the predeclared typeerror: theNamemethod returns"error". It is also what happens with the predeclared typeint.I think that implies that
comparableis a defined type, defined in terms of a magic interface type, just asintis a defined type defined in terms of a magic integer type. I don't know what consequences that would have for the go/types package, and it's not necessarily essential that go/types and reflect act the same way.The underlying type of
errorthough is noterror, it's the respective interface literal. This is different from other predeclared types such asint.Making
comparablea defined type likeintis also a possibility, and perhaps the more correct choice. @findleyr is correct though that this will require some changes that will ripple through various packages' APIs because we'll add a new basic type. But that may be cleaner than using an alias to an interface which still needs some magic bit to indicate it is the comparable interface (this shows up in imports, for instance).FWIW, when I wrote it my comment I didn't see much advantage to having
comparablebe a basic type. If we decide that is most correct, we should represent it accurately ingo/types.29 remaining items
It would be an interesting story to hear about the failure due to the proposal doc have only two places mentioning operator method but none of them mentioned about the sunk of that approach and only says "unplanned".
It would be an interesting story to hear about the failure due to the proposal doc have only two places mentioning operator method but none of them mentioned about the sunk of that approach and only says "unplanned".
There's only so much time in one's life to write down every single path taken which ended in a dead end. Sometimes it's just two short mentions... :-)
Reacted by Oleg Kovalov- Reacted by Beoran, Changkun Ou and Oleg Kovalov
Change https://golang.org/cl/381896 mentions this issue:
spec: add section on comparable constraintWhen printing the underlying type of
comparable, we can printinterface{comparable}which is a valid Go type.In short: The underlying type of
comparableis not itself. Instead we definecomparablesimilar toerror, as a defined type with a magic underlying type that still can be printed as valid Go.I think this should be reflected by the declaration of
comparablein thebuiltindocumentation package:https://github.com/golang/go/blob/master/src/builtin/builtin.go#L102
-type comparable comparable +type comparable interface{ comparable }
- added 4 commits that reference this issue
on Jun 21, 2022 - locked and limited conversation to collaborators
on Jun 22, 2023 - added a commit that references this issue
on Apr 29, 2024
Title says it all. Reminder issue.
cc: @ianlancetaylor
cc: @findleyr
cc: @mdempsky