3 ms·

> But the standard generic does not fit very well with go type system, so.... Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't

> But the standard generic does not fit very well with go type system, so.... Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.

jstimpfle 8y ago
> Arrays/Maps/Slices They are widely used data structures and so, in the opinion of the Go creators, justified separate specialized implementations in the Go compiler. In other words, there isn't actually a Generics system in the language (I don't actually know this, correct me if I'm wrong). For various reasons. There are quite a few talks and design docs from Rob Pike and Russ Cox if you look for them.
- latronic_notron 8y ago
  Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go. And generics aren't just for abstract data structures, there are other uses as well.
  - jstimpfle 8y ago
    I think you've misunderstood what I said. For example here: https://golang.org/src/go/parser/parser.go https://golang.org/src/go/parser/parser.go you can clearly see how e.g. token.MAP is a special case. func (p *parser) tryIdentOrType() ast.Expr { .... case token.MAP: return p.parseMapType() There is a special-cased function parseMapType() function in the Go parser. This isn't generic at all. I mean even the syntax (as in func foo(bar map[String]int) ...) does not seem to be generic at all. Yes, you can use any type as keys and values. But that's a far cry from an abstract system that lets the user define any parameterizable data type. And that's for good reason: By hardcoding just the most important parameterizable data types, the problems that an abstract system would bring can be avoided.
    - latronic_notron 8y ago
      Yes, I'm aware that they're a special case. What I mean is that this is exactly what is traditionally called "generics" or "parametric polymorphism" in PL literature. Go's Map/Array/Slice called "predefined generic types" in some literature.

> But the standard generic does not fit very well with go type system, so.... Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.

jstimpfle 8y ago

> Arrays/Maps/Slices They are widely used data structures and so, in the opinion of the Go creators, justified separate specialized implementations in the Go compiler. In other words, there isn't actually a Generics system in the language (I don't actually know this, correct me if I'm wrong). For various reasons. There are quite a few talks and design docs from Rob Pike and Russ Cox if you look for them.

latronic_notron 8y ago
Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go. And generics aren't just for abstract data structures, there are other uses as well.
- jstimpfle 8y ago
  I think you've misunderstood what I said. For example here: https://golang.org/src/go/parser/parser.go https://golang.org/src/go/parser/parser.go you can clearly see how e.g. token.MAP is a special case. func (p *parser) tryIdentOrType() ast.Expr { .... case token.MAP: return p.parseMapType() There is a special-cased function parseMapType() function in the Go parser. This isn't generic at all. I mean even the syntax (as in func foo(bar map[String]int) ...) does not seem to be generic at all. Yes, you can use any type as keys and values. But that's a far cry from an abstract system that lets the user define any parameterizable data type. And that's for good reason: By hardcoding just the most important parameterizable data types, the problems that an abstract system would bring can be avoided.
  - latronic_notron 8y ago
    Yes, I'm aware that they're a special case. What I mean is that this is exactly what is traditionally called "generics" or "parametric polymorphism" in PL literature. Go's Map/Array/Slice called "predefined generic types" in some literature.