spec: allow eliding interface{ } in constraint literals

[fzipp]

I propose an additional rule for constraints in type parameter lists:

[T nonInterfaceType] ≡ [T interface{~nonInterfaceType}]

Rationale:

All functions of the proposed maps package (#47649) and most functions of the slices package (#45955, #47203) currently use constraints from the constraints package (#45458) for maximum generality. A hypothetical chans package would probably be similar (there's already a proposal for constraints.{ReadOnlyChan|WriteOnlyChan}: #48366). Some excerpts:

func EqualFunc[M1 constraints.Map[K, V1], M2 constraints.Map[K, V2], K comparable, V1, V2 any](m1 M1, m2 M2, cmp func(V1, V2) bool) bool

func Clone[S constraints.Slice[T], T any](s S) S

With this proposal these would become:

func EqualFunc[M1 map[K]V1, M2 map[K]V2, K comparable, V1, V2 any](m1 M1, m2 M2, cmp func(V1, V2) bool) bool

func Clone[S []T, T any](s S) S

The benefit:

• constraints.{Slice|Map|Chan|ReadOnlyChan|WriteOnlyChan} would not be necessary at all.
• No visual incongruency between plain old Go types like map[K]V, []T, chan T, <-chan T, chan<- T and their accompanying constraints.

This proposal stems from the discussion under #47330 (reply in thread)

Summary:

  [M map[K]V, K comparable, V any]
≡ [M interface{~map[K]V}, K comparable, V any]
≡ [M constraints.Map[K, V], K comparable, V any]

  [S []T, T any]
≡ [S interface{~[]T}, T any]
≡ [S constraints.Slice[T], T any]

  [C <-chan T, T any]
≡ [C interface{~<-chan T}, T any]
≡ [C constraints.ReadOnlyChan[T], T any]

  [C chan<- T, T any]
≡ [C interface{~chan<- T}, T any]
≡ [C constraints.WriteOnlyChan[T], T any]

  [C chan T, T any]
≡ [C interface{~chan T}, T any]
≡ [C constraints.Chan[T], T any]

[ianlancetaylor]

CC @griesemer

[griesemer]

This is an interesting idea and we had (internally to the Go team) discussed essentially the same thing: writing a type expression X in constraint position as syntactic sugar for interface{X}. I think there's something to it, but we haven't quite figured out (not have spent the time on) to determine how such an idea would fit smoothly in to the rest of the type system.

In any case, the proposal would have to be generalized a bit. For instance, we would want to say int|string instead of interface{int|string}. Also, it's not clear exactly when the ~ can be omitted and why.

[ianlancetaylor]

If we do this, I don't think we should automatically insert a ~. That seems like unnecessary magic. That would give us

func EqualFunc[M1 ~map[K]V1, M2 ~map[K]V2, K comparable, V1, V2 any](m1 M1, m2 M2, cmp func(V1, V2) bool) bool

func Clone[S ~[]T, T any](s S) S

[fzipp]

In my imagination it's not "type set expression hoisted to type parameter list level", hence no | or ~. I intended to keep more complex and nuanced constraint definitions inside interfaces. I see it as "expand non-interface type into its sole useful constraint form". It is admittedly some amount of magic.

[fzipp]

I know it's probably too late for syntax changes re. constraints, but I personally would have preferred this:

My preference                             Vs. current design

[T interface { M() }]                     [T interface { M() }]
[T nonInterfaceType]                      [T interface { ~nonInterfaceType }]
[T union {A|B|C}]                         [T interface { ~A|~B|~C }].               
[T interface { nonInterfaceType; M() }]   [T interface { ~nonInterfaceType; M() }] 
[T interface { union {A|B|C}; M() }]      [T interface { ~A|~B|~C; M() }] 

With union being a non-interface type as well. The rule would have been simple: non-interface types match approximately when used as constraints, and they match exactly when used as regular types:

var x nonInterfaceType
var x union { A|B|C }

No tilde, and types like map[K]V could act directly as constraints.Map[K, V] etc.

[ianlancetaylor]

@fzipp If we want to make this change, let's keep this issue tightly focused on this specific change, not on a discussion of possible alternative syntaxes. Thanks.

[griesemer]

We might be able to say that a constraint is simply a type set. A type set may be expressed through an interface (as we do now), but it may also be a type expression of the form ~T or A|B. Additionally, we could say that an ordinary type T represents the type set interface{T} if we expect a type set. Syntactically, we'd have to allow type expressions of the form ~T and A|B outside of an interface (in constraint position only).

Or, looking from a slightly different angle, we could say that writing T, ~T , or A|B in constraint position is a form of syntactic sugar for interface{T}, interface{~T} , or interface{A|B}.

[rsc]

Agree with @ianlancetaylor about the ~ not being tied to the shortening.
At that point [C X] and [C interface{X}] are just the same.

It's already the case that [C interface{X}] and [C interface{interface{X}}] are the same,
so that makes the shortening safe 100% of the time.

And it would let us remove constraints.Map, constraints.Slice, etc.
Those just get spelled '~' now, as in [M ~map[K]V].

@griesemer will prototype and prepare a CL showing the effect on code.

[fzipp]

I'm ok with it if this is the preferred variant.

[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

[benhoyt]

This is definitely a readability win: I couldn't understand why the constraints.Map[K, V] thing was necessary at first at all, not to mention it'd be annoying to have to import and it takes up a lot of space. As a (newbie) code reader, to understand why it wasn't just map[K]V, you'd have to go to the constraints package docs, find the Map type, look at its definition, and notice the ~. With this proposed syntax, you'd just have to understand what ~ means. (I do prefer it without the ~, but I know what it means and can see the desire to avoid magically implying it.)

[akavel]

@rsc I'm not tracking all the (apparently more numerous than I thought) proposals related to generics, so I'd like to ask, if that's ok: will the discussion around this proposal temporarily suspend introduction of the constraints package (until this one is decided)? I'm not sure what's the status of the latter, but it would feel weird if constraints.Map were e.g. to be introduced with Go 1.18, just to become insta-legacy if this one (#48424) doesn't make it to Go1.18 (or wherever generics are to be introduced) yet possibly lands in (say) Go1.19. (In fact, I'm kinda guessing that's probably one of the main reasons you got this one on such a fast track, still I'm curious if you'd be ok with some explicit statement on the relation between the two. Thanks!)

[ianlancetaylor]

@akavel I'm confident that this proposal will be either accepted or declined before Go 1.18. If accepted, we should then consider removing constraints.Map, constraints.Slice, and constraints.Chan.

[gopherbot]

Change https://golang.org/cl/353133 mentions this issue: cmd/compile/internal/types2: allow eliding interface in constraint literals

[gopherbot]

Change https://golang.org/cl/353139 mentions this issue: cmd/compile/internal/types2: accept constraint literals with elided interfaces

[gopherbot]

Change https://golang.org/cl/353389 mentions this issue: cmd/compile: accept constraint literals with elided interfaces

[gopherbot]

Change https://golang.org/cl/353395 mentions this issue: x/tools/go/internal/gcimporter: exclude a file from TestImportTypeparamTests

[gopherbot]

Change https://golang.org/cl/353396 mentions this issue: cmd/compile/internal/types2: mark implicit interfaces as such

[griesemer]

This is now implemented in the compiler in the master branch at tip so we can explore this in practice. Note that this proposal has not been accepted yet, so don't write code that you expect to remain valid a month from now...

Only the compiler understands this notation at the moment, tools such as gofmt, vet, etc. cannot handle this yet.

If the proposal is not accepted, we can quickly disable the feature by changing a flag in the compiler.

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

[gopherbot]

Change https://golang.org/cl/355709 mentions this issue: cmd/compile/internal/syntax: remove AllowTypeSets mode

[griesemer]

This has been implemented in the compiler and go/types and go/print. @findleyr is there more to do on the std library side or can we close this (and track additional work separately)?

[findleyr]

@griesemer I've filed #49040 to track adding the implicit bit to export data, so I think this issue can be closed.

[gopherbot]

Change https://golang.org/cl/357796 mentions this issue: go/types, types2: add the Interface.MarkImplicit method

[gopherbot]

Change https://golang.org/cl/359258 mentions this issue: constraints: remove Slice/Map/Chan

[tooolbox]

I first proposed this in the slice functions discussion but didn't get anywhere. Admittedly I was a little off-topic. Imagine my surprise just now when I find the official Generics Tutorial is using union syntax directly in type arguments, and then the Proposal is using ~[]E as well.

I had been resigned to using constraints.Slice and such. I just want to express my thanks to @fzipp for making an actual proposal and the Go Team members for accepting this change, I think it's a big improvement.

In terms of the philosophy mentioned by @griesemer :

We might be able to say that a constraint is simply a type set. A type set may be expressed through an interface (as we do now), but it may also be a type expression of the form ~T or A|B. Additionally, we could say that an ordinary type T represents the type set interface{T} if we expect a type set. Syntactically, we'd have to allow type expressions of the form ~T and A|B outside of an interface (in constraint position only).

Or, looking from a slightly different angle, we could say that writing T, ~T , or A|B in constraint position is a form of syntactic sugar for interface{T}, interface{~T} , or interface{A|B}.

Both work, my opinion is that the former is superior. A type is T, full stop. A type set is T or some expansion of the set via union or inclusion of descendants, or narrowing by requiring behavior in the form of methods.

The real litmus test is how well devs work with that mental model. I for one love it.

[jub0bs]

Shouldn't there be a go vet check for type constraints consisting of a single non-generic concrete type? Here is a contrived example:

func foo[T int](t T) {
   fmt.Println(t)
}

Unless I'm missing something, the type parameter doesn't provide any benefit and the function could as well be declared as

func foo(i int) {
   fmt.Println(i)
}

[findleyr]

@jub0bs please feel free to open a proposal for such a vet check.

Vet has three conditions for new checks:
https://go.dev/src/cmd/vet/README

I suspect that what you suggests meets the Correctness and Precision requirements, but may not meet the Frequency requirement. This could be discussed in a proposal.