4 ms·

It's interesting how "angle brackets vs. square brackets" is such an issue for many Go programmers commenting on the generics proposals (including earlier ones)

It's interesting how "angle brackets vs. square brackets" is such an issue for many Go programmers commenting on the generics proposals (including earlier ones). Maybe it is just revealing where those programmers are coming from. Java and C++? Angle brackets! Eiffel, Scala? Square brackets! Are there any parser considerations (like <Foo <Bar>> being an issue in C++, afair), or is it just taste (or Scala vs. C++ background)?

fooker 6y ago
> <Foo <Bar>> is an issue in C++ Used to be, a long time ago.
enricozb 6y ago
There can be parser considerations: a < b can be greedily interpreted as a comparison, despite the next character being a > a [ b can be greedily interpreted as accessing a field in a map, despite the next character being a ] It may be easier to branch in one of those cases instead of the other. Not at all familiar with the potential issues (if any) in go, but this is from experience in writing a few languages.
kyrra 6y ago
This is talked about here: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java https://go.googlesource.com/proposal/+/refs/heads/master/des... This line of code seems to say why is troublesome given Go's other syntax: a, b = w < x, y > (z)
lhorie 6y ago
> Are there any parser considerations Yes, in fact I can point to two different cases related to usage of angled brackets for generics: 1) Typescript claims to be a superset of JS, but it isn't, precisely because of this. `a<b,c>(d)` parses as a call to `a(d)` in TS, but parses to two comparisons in JS 2) D explicitly chose `!(foo)` syntax for templates over the `<foo>` syntax in order to avoid the parsing ambiguities problem
asplake 6y ago
I don’t do Go, but square brackets make perfect sense to me. Can’t see it being a big issue in the long run

fooker 6y ago

> <Foo <Bar>> is an issue in C++ Used to be, a long time ago.

enricozb 6y ago

There can be parser considerations: a < b can be greedily interpreted as a comparison, despite the next character being a > a [ b can be greedily interpreted as accessing a field in a map, despite the next character being a ] It may be easier to branch in one of those cases instead of the other. Not at all familiar with the potential issues (if any) in go, but this is from experience in writing a few languages.

kyrra 6y ago

This is talked about here: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java https://go.googlesource.com/proposal/+/refs/heads/master/des... This line of code seems to say why is troublesome given Go's other syntax: a, b = w < x, y > (z)

lhorie 6y ago

> Are there any parser considerations Yes, in fact I can point to two different cases related to usage of angled brackets for generics: 1) Typescript claims to be a superset of JS, but it isn't, precisely because of this. `a<b,c>(d)` parses as a call to `a(d)` in TS, but parses to two comparisons in JS 2) D explicitly chose `!(foo)` syntax for templates over the `<foo>` syntax in order to avoid the parsing ambiguities problem

asplake 6y ago

I don’t do Go, but square brackets make perfect sense to me. Can’t see it being a big issue in the long run