Partial type argument list restriction

[Quim Muntal]

The Go spec says:

A partial type argument list specifies a prefix of the full list of type arguments, leaving the remaining arguments to be inferred. Loosely speaking, type arguments may be omitted from "right to left" (Source).

This means it is legal:

type  E[T1, T2 any]  struct{ … }

T[]

T[int]

T[int, int]

And this is not legal:

T[_, int]

T[, int]

I'm wondering which is the reasoning behind this restriction. Is it a limitation of the current implementation? Is it a design limitation? Is it just that nobody asked for it?

I'm posting this question because I've seen several colleagues (and myself) trying to use partial type lists which do not follow the "type arguments can be omitted from right to left" rule, and the first impression when you see the compiler yielding "syntax error: unexpected comma, expecting expression" is at least confusing. 

[Ian Lance Taylor]

We would have to define some syntax for the omitted type argument.
You've implicitly suggested two possible syntaxes above: using an
underscore, or omitting the type argument entirely. Neither seems
perfect.

More importantly, we don't see any use case for this feature. The
order of type parameters is largely irrelevant. Do you have a use
case where some callers want to specify some type arguments and some
other callers want to specify a different set of type arguments? Bear
in mind that making generics as simple as possible, while still
permitting people to write generic code, is an important design goal.
Type inference is a convenience feature. It is always possible to
write down all the type arguments. It is more important that type
inference be very clear and unconfusing than it is for type inference
to be applicable in all cases.

Ian