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