I don't much like square brackets or angle brackets or guillemets. But here is a different way of reducing the need for parentheses at least for the common case:
A proposal for fewer irritating parentheses! One thing to note is that generic functions & types are *different* from existing things like const, func, type, var. As such they should have their own declaration marker. For example gen T type pair struct { a, b T } // contrast with type pair(type T) ... gen T,U type W struct { a T; b U } // contrast with type W(type T, U) ... gen T func Print(s []T) {...} // print a slice of T These function/type/method generics are used by *prepending* the type: var x int pair // a pair of ints var y (int, int pair) W // here we have to use parentheses int Print([]int{1,2,3}) // print a slice of ints qq := int pair pair{{1,2},{3,4}} // a pair of a pair of ints ww := (int, int) W pair{{1,2},{3,4}} This use may seem weird if you are used to C/C++. I find it more readable than having to deal with extra parentheses. "int pair" clearly says a pair of ints and so on. What is more, if in future types are allowed to be *inferred* for generic function calls, you can simply drop the type prefix. If there is still a parsing ambiguity, I'd suggest adding a - as in int-pair. Additional type syntax rule: type: ... | type generic-type| (type-list) generic-type or type: ... | type "-" generic-type | (type-list) "-" generic-type FWIW I thought of this four weeks ago (June 16). > On Jul 14, 2020, at 3:29 PM, 'gri' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > Correction: The last paragraph in the post below should have said: "In Go, > type information is not available at parse time". (Of course, type > information is available at compile time.) > > On Tuesday, July 14, 2020 at 2:56:01 PM UTC-7 gri wrote: > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/97a2914f-3e54-4994-974f-135e11f11117n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/97a2914f-3e54-4994-974f-135e11f11117n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/3E782FE9-D854-45D8-B454-EC869409EA5D%40iitbombay.org.