5 ms·

On <> syntax, this has been discussed quite a bit. () were chosen to avoid ambiguous parsing. Also note that generic methods are not allowed in the current des

On <> syntax, this has been discussed quite a bit. () were chosen to avoid ambiguous parsing. Also note that generic methods are not allowed in the current design, only generic functions. The new draft design ( https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des... ) discusses both of these points. I recommend everyone who is interested in this topic read the design spec, ideally before commenting.

mdlayher 6y ago
Exactly. Thanks!
twblalock 6y ago
On the <> syntax, why not improve the parser? Every language that uses <> for generics has a parser that is able to distinguish between generics and the "less than" operator, and it seems odd that Go developers think it can't be done efficiently.
- 8192kjshad09- 6y ago
  Go developers like to claim that the reason the Go compiler is fast is because it's "simple to parse". Unfortunately this doesn't make a lot of sense as parsing is typically only 1-5% of the total compile time.
  - sacado2 6y ago
    It's not only about the main compiler. Go has tons of third-party tools (linters mainly) that can parse go code, because it's so easy to write one. Most of them wouldn't exist if parsing was a PITA.
    - Groxx 6y ago
      Those almost universally use the "ast" package provided by the stdlib.
- monkeyfacebag 6y ago
  In my opinion, the new design doc clearly characterizes this as a design goal of the parser, rather than a hard constraint that cannot be resolved. "Resolving that requires effectively unbounded lookahead. In general we strive to keep the Go parser simple." It's totally fair to question the tradeoff - should having a simple parser outweigh the potential ergonomic benefit of <>? I don't know. The forum for this is probably the golang-nuts group.
  - mpoteat 6y ago
    It's all a matter of where you accept the complexity - in the compiler, in the language, or in the downstream applications. In my view it's an obvious choice to choose a more complicated compiler on exchange for simpler downstream applications...
  - nemetroid 6y ago
    The design doc doesn't say "simple", it says "efficient". I think "simpler" would have been a stronger argument. While using <> would make the parser more complex, I have a hard time seeing that making a meaningful performance difference in a compilation context. Maybe if you're parsing a lot of Go without actually compiling it, but that doesn't seem like a use case to optimize for.
- Sharlin 6y ago
  C++ and Rust require extra disambiguating syntax in some contexts (C++ the `foo.template bar<T>()` syntax, Rust the "superfish operator" `foo.bar::<T>()`. Java works around the problem by awkwardly putting the generic argument list in front of the method name (`foo.<T>bar()`). I don't know about C#.
  - steveklabnik 6y ago
    (teeny tiny note: turbofish, not superfish)
    - Sharlin 6y ago
      Oops :D
  - DougBTX 6y ago
    C# is `foo.bar<T>()`, I’m not sure what compromises that had to make for that to work but from an end-user perspective it works well.
    - oxnrtr 6y ago
      They parse it one way, and if they figure out the other parse option was right, they go back and fix the parse tree. Basically, unlimited look-ahead.
      - lostmsu 6y ago
        Is it somehow a problem?
  - oxnrtr 6y ago
    Using [] is the optimal choice for languages in general, but they can't even use that because they blew away that syntax for indexing.
    - Sharlin 6y ago
- qtplatypus 6y ago
  It is not a question of "Improve" but a question of dealing with tradeoffs. The Go parser is built so that at every stage it is totally unambiguous what the parser has to do. This reduces the amount of state that the parser has to carry around and makes the error messages for syntax errors easier to generate. Languages that use <>'s for generics have to look at a larger amount of the code when parsing to work out what to do.
- apta 6y ago
  The golang approach has been to dumb down the parser, at the expense of making it more complex for users.
  - jatone 6y ago
    there is no complexity tradeoff for users here.
    - apta 6y ago
      Angle brackets are easier to parse for humans.
- teleforce 6y ago
  The main reason is probably that by omitting <> for generics makes the symbol table unnecessary as part of the compilation stage. Go and D are the two modern languages that are avoiding symbol table like a plague for faster compilation time, i.e. the code should be parseabled without having to look things up in a symbol table .
lsllc 6y ago
Ah, right, I missed this: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#methods-may-not-take-additional-type-arguments https://go.googlesource.com/proposal/+/refs/heads/master/des... Hmmm ... not sure how I feel about that. Ok so my original example becomes this: func (obj *SomeType) Foo(type K, V, Q comparable)(key K, val V) (*OtherType(Q, V), error) { ... } Which is only slightly better [without the generic type]. Don't get me wrong, I'm a big fan of Go, but I'm kind of on the fence about generic types. I've made do with casting interfaces and type-casts for many years and I'm OK with it (honestly, glad to not be a C++ or Java programmer anymore).
- mseepgood 6y ago
  > Ok so my original example becomes this No, you still don't understand. Methods can't have additional type parameters, only functions. This part is not allowed in your "example": (type K, V, Q comparable)
  - lsllc 6y ago
    The doc says: > Generic types can have methods. The receiver type of a method must declare the same number of type parameters as are declared in the receiver type's definition. They are declared without the type keyword or any constraint. So my original example should have been: func (obj *SomeType(K, V)) Foo(key K, val V) (*OtherType(K, V), error) { ... } (hopefully this is now correct!).

mdlayher 6y ago

Exactly. Thanks!

twblalock 6y ago

On the <> syntax, why not improve the parser? Every language that uses <> for generics has a parser that is able to distinguish between generics and the "less than" operator, and it seems odd that Go developers think it can't be done efficiently.

8192kjshad09- 6y ago
Go developers like to claim that the reason the Go compiler is fast is because it's "simple to parse". Unfortunately this doesn't make a lot of sense as parsing is typically only 1-5% of the total compile time.
- sacado2 6y ago
  It's not only about the main compiler. Go has tons of third-party tools (linters mainly) that can parse go code, because it's so easy to write one. Most of them wouldn't exist if parsing was a PITA.
  - Groxx 6y ago
    Those almost universally use the "ast" package provided by the stdlib.
monkeyfacebag 6y ago
In my opinion, the new design doc clearly characterizes this as a design goal of the parser, rather than a hard constraint that cannot be resolved. "Resolving that requires effectively unbounded lookahead. In general we strive to keep the Go parser simple." It's totally fair to question the tradeoff - should having a simple parser outweigh the potential ergonomic benefit of <>? I don't know. The forum for this is probably the golang-nuts group.
- mpoteat 6y ago
  It's all a matter of where you accept the complexity - in the compiler, in the language, or in the downstream applications. In my view it's an obvious choice to choose a more complicated compiler on exchange for simpler downstream applications...
- nemetroid 6y ago
  The design doc doesn't say "simple", it says "efficient". I think "simpler" would have been a stronger argument. While using <> would make the parser more complex, I have a hard time seeing that making a meaningful performance difference in a compilation context. Maybe if you're parsing a lot of Go without actually compiling it, but that doesn't seem like a use case to optimize for.
Sharlin 6y ago
C++ and Rust require extra disambiguating syntax in some contexts (C++ the `foo.template bar<T>()` syntax, Rust the "superfish operator" `foo.bar::<T>()`. Java works around the problem by awkwardly putting the generic argument list in front of the method name (`foo.<T>bar()`). I don't know about C#.
- steveklabnik 6y ago
  (teeny tiny note: turbofish, not superfish)
  - Sharlin 6y ago
    Oops :D
- DougBTX 6y ago
  C# is `foo.bar<T>()`, I’m not sure what compromises that had to make for that to work but from an end-user perspective it works well.
  - oxnrtr 6y ago
    They parse it one way, and if they figure out the other parse option was right, they go back and fix the parse tree. Basically, unlimited look-ahead.
    - lostmsu 6y ago
      Is it somehow a problem?
- oxnrtr 6y ago
  Using [] is the optimal choice for languages in general, but they can't even use that because they blew away that syntax for indexing.
  - Sharlin 6y ago
qtplatypus 6y ago
It is not a question of "Improve" but a question of dealing with tradeoffs. The Go parser is built so that at every stage it is totally unambiguous what the parser has to do. This reduces the amount of state that the parser has to carry around and makes the error messages for syntax errors easier to generate. Languages that use <>'s for generics have to look at a larger amount of the code when parsing to work out what to do.
apta 6y ago
The golang approach has been to dumb down the parser, at the expense of making it more complex for users.
- jatone 6y ago
  there is no complexity tradeoff for users here.
  - apta 6y ago
    Angle brackets are easier to parse for humans.
teleforce 6y ago
The main reason is probably that by omitting <> for generics makes the symbol table unnecessary as part of the compilation stage. Go and D are the two modern languages that are avoiding symbol table like a plague for faster compilation time, i.e. the code should be parseabled without having to look things up in a symbol table .

lsllc 6y ago

Ah, right, I missed this: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#methods-may-not-take-additional-type-arguments https://go.googlesource.com/proposal/+/refs/heads/master/des... Hmmm ... not sure how I feel about that. Ok so my original example becomes this: func (obj *SomeType) Foo(type K, V, Q comparable)(key K, val V) (*OtherType(Q, V), error) { ... } Which is only slightly better [without the generic type]. Don't get me wrong, I'm a big fan of Go, but I'm kind of on the fence about generic types. I've made do with casting interfaces and type-casts for many years and I'm OK with it (honestly, glad to not be a C++ or Java programmer anymore).

mseepgood 6y ago
> Ok so my original example becomes this No, you still don't understand. Methods can't have additional type parameters, only functions. This part is not allowed in your "example": (type K, V, Q comparable)
- lsllc 6y ago
  The doc says: > Generic types can have methods. The receiver type of a method must declare the same number of type parameters as are declared in the receiver type's definition. They are declared without the type keyword or any constraint. So my original example should have been: func (obj *SomeType(K, V)) Foo(key K, val V) (*OtherType(K, V), error) { ... } (hopefully this is now correct!).