We have received a variety of feedback on the generics draft design
<https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md>
(blog <https://blog.golang.org/generics-next-step>). Thanks to everyone who
took the time to read it, play with generics code in the playground
<https://go2goplay.golang.org/>, file issues, and send us their thoughts.
Not unexpectedly, many people raised concerns about the syntax,
specifically the choice of parentheses for type parameter declarations and
generic type and function instantiations.
A typical computer keyboard provides four easily accessible pairs of
single-character symmetrical "brackets": parentheses ( and ), square
brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses
curly braces to delineate code blocks, composite literals, and some
composite types, making it virtually impossible to use them for generics
without severe syntactic problems. Angle brackets require unbounded parser
look-ahead or type information in certain situations (see the end of this
e-mail for an example). This leaves us with parentheses and square
brackets. Unadorned square brackets cause ambiguities in type declarations
of arrays and slices, and to a lesser extent when parsing index
expressions. Thus, early on in the design, we settled on parentheses as
they seemed to provide a Go-like feel and appeared to have the fewest
problems.
As it turned out, to make parentheses work well and for
backward-compatibility, we had to introduce the type keyword in type
parameter lists. Eventually, we found additional parsing ambiguities in
parameter lists, composite literals, and embedded types which required more
parentheses to resolve them. Still, we decided to proceed with parentheses
in order to focus on the bigger design issues.
The time has come to revisit this early decision. If square brackets alone
are used to declare type parameters, the array declaration
type A [N]E
cannot be distinguished from the generic type declaration
type A[N] E
But if we are comfortable with the extra type keyword, the ambiguity
disappears:
type A[type N] E
(When we originally dismissed square brackets, the type keyword was not yet
on the table.)
Furthermore, the ambiguities that arise with parentheses appear not to
arise with square brackets. Here are some examples where extra parentheses
are not needed with square brackets:
using () using []
func f((T(int)) func f(T[int])
struct{ (T(int)) } struct{ T[int] }
interface{ (T(int)) } interface{ T[int] }
[](T(int)){} []T[int]{}
To test this better understanding, and to get a feel for this alternative
notation, we will begin to make changes to our prototype implementation
such that it accepts either parentheses or square brackets (only one or the
other) in a generic Go package. Those changes will first appear as commits
to the dev.go2go branch
<https://go.googlesource.com/go/+/refs/heads/dev.go2go>, and eventually in
the playground <https://go2goplay.golang.org/>.
If square brackets don't lead to unforeseen issues, we have another fully
explored notation to choose from, which will allow us to make a more
informed decision.
- gri, iant
PS: For ambiguities with angle brackets consider the assignment
a, b = w < x, y > (z)
Without type information, it is impossible to decide whether the right-hand
side of the assignment is a pair of expressions
(w < x), (y > (z))
or whether it is a generic function invocation that returns two result
values
(w<x, y>)(z)
In Go, type information is not available at compile time. For instance, in
this case, any of the identifiers may be declared in another file that has
not even been parsed yet.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAKy0tf4agu1nNdwc%3DeZQt-KpvrD8XcFm502x46tkriz3gEJUXg%40mail.gmail.com.
