One way to distinguish between type A[N] E and type A [N]E is to be more space-sensitive and, for example, disallow whitespace between a type name and the opening square bracket when it signifies type parameters.
Dňa utorok, 14. júla 2020 23:56:01 UTC+2 gri napísal(a): > > 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/6150dc01-0add-4bee-b3cc-4bc4429d8f11o%40googlegroups.com.
