It certainly does for me. It ties into this quote:
> Why not use the syntax F<T> like C++ and Java?
A great number of us are used to seeing <> rather than [] for generics.
It would seem limitations in Go's parser outrank a popular norm.
> Why not use the syntax F<T> like C++ and Java?
A great number of us are used to seeing <> rather than [] for generics.
It would seem limitations in Go's parser outrank a popular norm.
As an outsider it appears to me that the choice for square brackets has been made mostly for stylistic non-technical reasons, but perhaps politically that would be difficult to rationalise to the user-base! Making whitespace significant before comparison/shift operators (matching the gofmt layout) surely solves the stated practical issue of lookahead parsing; although I admit many language geeks would say significant space characters were an ugly solution.
To agree with you: there is a really good discussion on the downsides of <> here —https://lobste.rs/s/fmcviy/language_designers_stop_using_for — certainly square brackets are used for generics in other languages (Scala, Python, Nim, Eiffel).
Regardless, the point is moot, given that the syntax is now concrete!
> then by the same token <> is also easy to confuse with comparison operators
Not really, given that comparison/shift operators are not used in types, whereas [] is used in types. Perhaps go-lang wanted to reserve angle brackets for constraint operators a la Scala <: et al. </wink>.
Disclaimer: I have little experience with generics or language design. I am just very curious if there is a divergence between the stated reasons for the design, versus any unstated reasons.