spec: document definition of comparable

[griesemer]

Title says it all. Reminder issue.

cc: @ianlancetaylor
cc: @findleyr
cc: @mdempsky

[rsc]

What would it be an alias of?

[griesemer]

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/types API: This code prints the underlying type of comparable. Because there's no proper literal for it, it prints interface{} which is misleading at best. The actual underlying type behaves correctly (test).

If we make comparable an alias for this magic interface literal, the underlying type would be itself and could be printed as comparable.

Perhaps it should be a "basic" type like int, etc.

[rsc]

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.

[findleyr]

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 comparable an alias for "the magic comparable interface" makes sense to me. Similar to any, we'd have special handling for formatting "the magic comparable interface" as comparable, but unlike any we don't have to implement this via pointer tracking: we have a bit on Interface that tells us if it is comparable.

[griesemer]

Ok, we all agree that comparable'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.

[gopherbot]

Change https://golang.org/cl/380754 mentions this issue: go/types, types2: underlying type of comparable is itself

[ianlancetaylor]

If we ever permit variables to have type comparable, we'll have to explain what happens if you call reflect.TypeOf on a pointer to such a variable. Presumably the reflect.Kind will be Interface, because it is, after all, an interface type. For that reflect.Type, it seems to me that the Name method should return "comparable". That is what happens with the predeclared type error: the Name method returns "error". It is also what happens with the predeclared type int.

I think that implies that comparable is a defined type, defined in terms of a magic interface type, just as int is 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.

[griesemer]

The underlying type of error though is not error, it's the respective interface literal. This is different from other predeclared types such as int.

Making comparable a defined type like int is 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).

[findleyr]

FWIW, when I wrote it my comment I didn't see much advantage to having comparable be a basic type. If we decide that is most correct, we should represent it accurately in go/types.

[griesemer]

cc: @danscales because this will also effect the representation of comparable in the compiler.

[ianlancetaylor]

I don't feel strongly about any of this, but I think we need to answer a couple of questions.

If we ever permit variables of comparable type, how will the reflect package distinguish them from variables of interface{} type?

Why should comparable be an alias when error and int are not aliases? Why is comparable different?

I don't see why comparable should be a basic type as such (though perhaps I misunderstand what a basic type is). It seems to me that comparable is an interface type. So one approach for the reflect package would be to make comparable a defined type (like int) defined in terms of an interface type, and add some way to determine whether all comparable types implement that interface. In fact something like that would seem to be required to support using the reflect package with an interface type that embeds comparable.

[griesemer]

If we agree that the underlying type of comparable is itself there are only two choices in the implementation: it's a basic type like int, or it's an alias to some magic interface literal: the underlying type of a basic type is that basic type, and the underlying type of a literal type is that literal type.

Because comparable is also an interface, it seemed to make sense to make it an alias for a magic interface type. Since we don't have a source code representation for that interface, we need to mark it somehow so we can recognize it. This matters for APIs and import/export. It may be an implementation "detail", but it's important to get it right lest we want to deal with special cases all over the place.

[griesemer]

We do have some precedent: unsafe.Pointer is a defined/named type (like int) and implemented as a basic type. However it does behave like a pointer in some situations (for instance, it cannot be the underlying type of a receiver base type). We have special cases in the type-checker for this because unsafe.Pointer is not represented like other pointers.

[timothy-king]

Narrow question: for comparable, what does (go/types.Type).Underlying() return today? What would it return if this was adopted?

[griesemer]

See #50791 (comment). It should always return itself.

[findleyr]

Regarding the behavior of comparable in reflect, if we were to allow it outside of constraint position: how would we distinguish interfaces that embed comparable? Wouldn't we need a new API to answer that question, independent of whether comparable itself has a name?

[danscales]

I'm not sure why the underlying type of comparable has to be itself.

Since we can't represent the underlying type of comparable in terms of anything else (i.e. it has no methods, but is different from empty interface), we clearly need a magic bit or new basic kind to distinguish that fundamental interface type - call it C.

Then, it seems to me we can either do type comparable C or type comparable = C.

As Ian points out, given that error is a defined type, why shouldn't comparable stay as a defined type? I.e. comparable is a defined type whose underlying type is the magic interface C (so type comparable C)

Of course, we do still have to have a method of printing and distinguishing C when reflect, etc. wants to look at it. I'm not sure that there is a good way other than a new basic kind.

[griesemer]

@danscales: see #50791 (comment) : What do we print for the underlying type of comparable if it's not itself? Note that the underlying type of a defined type is not itself, unless it's a basic type.

[ianlancetaylor]

@findleyr

Regarding the behavior of comparable in reflect, if we were to allow it outside of constraint position: how would we distinguish interfaces that embed comparable? Wouldn't we need a new API to answer that question, independent of whether comparable itself has a name?

No, we wouldn't. The reflect package does not need to distinguish interfaces that are the result of embedding from interfaces that simply list the same sets of methods. The reflect package only describes the runtime behavior of types, not the way in which they were defined.

For that matter, aliases are completely invisible in the reflect package.

[findleyr]

@ianlancetaylor

The reflect package only describes the runtime behavior of types, not the way in which they were defined.

That's exactly my point: how would we express the behavior that the interface pointed to by x can only hold comparable types?

type I interface { comparable }

var x *I

[danscales]

@danscales: see #50791 (comment) : What do we print for the underlying type of comparable if it's not itself? Note that the underlying type of a defined type is not itself, unless it's a basic type.

Yes, I agree that we still have to have something to print out for C and possible a new kind or magic bit for C. (I had already edited my previous comment to say something like that, but should have made a new comment.)

I think we could print out <underlyingComparable> or something like that for the underlying type of comparable. My point is that we don't have to make the underlying type of comparable be itself. We can make comparable similar to error - a defined type. But I realize it may be uglier in some ways (which are not usually seen).

[ianlancetaylor]

@findleyr Ah, sorry for misunderstanding. Yes, as I mentioned earlier, we would have to add some way to determine whether all comparable types implement that interface. As far as I can see this would have to be a new method on reflect.Type. I don't see any other approach that could work. In particular it would not work to introduce a new reflect.Kind.

[ianlancetaylor]

I guess my main concern about making comparable an alias is that this would be the only case in which we have an alias for a type that can not be expressed in any other way. It may still be the right choice, but it seems weird.

[findleyr]

@ianlancetaylor

Yes, as I mentioned earlier, we would have to add some way to determine whether all comparable types implement that interface

Apologies, I missed that you had mentioned that explicitly in your second comment. I was still thinking about your original comment :)

I think the fact that a new API would be required in any case makes it less important that the universe comparable type has a name.

[gopherbot]

Change https://golang.org/cl/380854 mentions this issue: spec: document the underlying type of comparable

[griesemer]

Per further discussions with @ianlancetaylor and @findleyr:

The updated spec already says that all predeclared types are named types. comparable can only be a named type if it's a defined type (like error), or a predeclared basic type (like int). For reasons outlined above, the latter is not a good option. Thus we need a defined type. Unless we break the language-wide invariant that the underlying type of a defined type cannot be a defined type, comparable as a defined type cannot be its own underlying type, after all. It can also not be an alias to a magic interface as that would not be a defined type.

Thus, we can define it as:

type comparable interface{ /* magically marked as comparable */ }

which is what we already have in the implementation. When printing the underlying type of comparable, we can print interface{comparable} which is a valid Go type.

In short: The underlying type of comparable is not itself. Instead we define comparable similar to error, as a defined type with a magic underlying type that still can be printed as valid Go.

[gopherbot]

Change https://golang.org/cl/381094 mentions this issue: go/types, types2: clean up the set up of error, comparable

[gopherbot]

Change https://golang.org/cl/381076 mentions this issue: Revert "spec: document the underlying type of comparable"

[beoran]

Just bike shedding but maybe interface {==} could be the magical one?

[changkun]

Isn't it going to be easier if we have operator method? No magic anymore:

type comparable[T any] interface {
    ==(t T) bool // == is the operator but also the name of the method
}

[griesemer]

Just bike shedding but maybe interface {==} could be the magical one?

It could but why introduce a new notation for something we'll never need? We have the name comparable.

Isn't it going to be easier if we have operator method? No magic anymore:

We've tried operator methods repeatedly over the course of developing generics. They have their own (numerous) problems. That ship has sailed (and sunk) a long long time ago.

Except for documentation, I think this issue is resolved. Thanks.

[changkun]

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".

[griesemer]

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... :-)

[ianlancetaylor]

@changkun https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-use-methods-instead-of-type-sets

[gopherbot]

Change https://golang.org/cl/381896 mentions this issue: spec: add section on comparable constraint

[fzipp]

When printing the underlying type of comparable, we can print interface{comparable} which is a valid Go type.

In short: The underlying type of comparable is not itself. Instead we define comparable similar to error, 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 comparable in the builtin documentation package:

https://github.com/golang/go/blob/master/src/builtin/builtin.go#L102

-type comparable comparable
+type comparable interface{ comparable }