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.shahbaz...@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+unsubscr...@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/CAOyqgcU9PxRYuBAQHfOOQaUOgH1OC2FVJF4ti3fYLpspDwXL8g%40mail.gmail.com.
