3 ms·

Built-in map and vector types are generic. E.g. map[int]*MyType Using interface{} is quite common in the absence of sum types (or inheritance with base class)

• foldr 4y ago
  >Built-in map and vector types are generic. I understand what people mean by this, but it's not true for any reasonable notion of 'generic'. Pre-generics Go no more has generic maps than C has generic arrays. Yes, you can declare a map or a slice of values of any given type, but you can't write a generic function that abstracts over these types. That's what is usually meant by 'generics'.
  • erik_seaberg 4y ago
    There were three or four generic types and a few generic functions (close, len, cap, make, append, delete, x[y], <-, ==, for-range, select), they just didn’t let normal users define new ones without forking the compiler.
    • foldr 4y ago
      I don’t think it makes sense to see built in operations on arrays and maps as generic functions. If 'len' was some kind of built-in generic function then you'd expect to be able to monomorphize it like this: func intLen(foo []int, lenfunc func ([]int) int) int { return lenfunc(foo) } intLen([]int{1,2,3}, len) There is just no sense in which Go 1.17 has “generic types” and (e.g.) C doesn’t. All statically typed languages allow you to define arrays of different types and use the same operators on these arrays. Go adds a handful of additional built in types (slices, maps, channels). The idea that some completely ordinary language features somehow constitute a crippled version of generics that has been 'turned off' for regular users seems to be an artefact of certain communities' hobbyhorsing over Go's (former) lack of generics.
      • erik_seaberg 4y ago
        As a thing that takes an argument and returns a result, I would have expected len to be an ordinary function. That I don’t is only because I remember the disappointing state of the language at launch.
  • maxiepoo 4y ago
    Sure but it's worth emphasizing that Go language designers gave these built-in collections the exorbitant privilege of being parameterized by a type and declaring that any new type created by a mere programmer has to be monomorphic.
    • foldr 4y ago
      > the exorbitant privilege of being parameterized by a type This is how built in collection types work in pretty much all statically typed languages. For example, here is an array of ints in C: int foo[] = { 1, 2, 3 }; We wouldn't usually say that C has 'generic arrays'. > any new type created by a mere programmer has to be monomorphic. Collections in (pre-Generics) Go are monomorphic. []foo and []bar are as different as foo and bar. That is why, for example, the first argument of sort.Slice has type 'any' (https://cs.opensource.google/go/go/+/go1.18.2:src/sort/slice.go;l=16 https://cs.opensource.google/go/go/+/go1.18.2:src/sort/slice...)
  • feffe 4y ago
    Yes, you are correct. I had not thought about it deeply. There are restrictions for what can be used as a map keys according to some built-in equality rules. And of course the types used as map keys and values are concrete types so you can't pass a map to generic functions pre generics. But was the built-in append function generic pre generics? I think it is?