You can use ... As a generic Chinese 你可以使用 ... 作为泛型标志 在2020年8月26日星期三 UTC+8 上午4:59:41<Ian Lance Taylor> 写道：
> Thanks for the note. Please see the discussion at > https://groups.google.com/d/msg/golang-nuts/iAD0NBz3DYw/VcXSK55XAwAJ . > > Ian > > On Tue, Aug 25, 2020 at 1:21 PM Kaveh Shahbazian > <kaveh.sh...@gmail.com> wrote: > > > > After playing in generics playground with a dozen of cases that came to > my mind, IMHO brackets seem to be more clear than parentheses for declaring > type parameters. Also using the type keyword before the type parameter > reduces the cognitive load drastically. > > > > type StateFn[type T] func(T) StateFn[T] // Good > > > > vs: > > > > type StateFn(type T) func(T) StateFn(T) // Not as clear as the previous > one > > > > It's hard to say if there are any practical alternatives to brackets - > according to the proposal. But angle brackets are not that ugly by > themselves. > > > > (I'm not sure if this approach is actually possible) > > > > The hash/number signs appear in the language specifications just once: > > > > type StateFn<#T> func(T) StateFn<#T> > > > > And the %T syntax is used to print types: > > > > type StateFn<%T> func(T) StateFn<%T> > > > > Then, that problematic example would become: > > > > a, b = w<#x,y>(z) > > > > or: > > > > a, b = w<%x,y>(z) > > > > On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 gri wrote: > >> > >> We have received a variety of feedback on the generics draft design > (blog). Thanks to everyone who took the time to read it, play with generics > code in the playground, 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, and eventually in the playground. > >> > >> > >> 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...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/a5fd4511-6930-442b-b9d6-c221bec7eb83n%40googlegroups.com > . > -- 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/2828b918-f21d-46db-a583-671b9d6b2112n%40googlegroups.com.
