Correct me if I am wrong but wouldn't square bracket syntax have an
ambiguity around calling a function pointer at a position in a slice:
z := []func() int{x, y};
a := z[0]();
https://play.golang.org/p/lekFJlvbRTD
On Tuesday, July 14, 2020 at 10:56:01 PM UTC+1 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/fd4b1a90-110e-4121-8e63-55ce72fc1b7bn%40googlegroups.com.
