[bakul]

Did you consider parameterized packages? The idea is you can declare a set of related objects/types/methods as well as have concrete type specific initialization. E.g.

  package stack[t]
  type Type []t
  func New() Type { return Type{} }
  ...
  

Then it can be used so:

  import s “stack”[int]
  var s1 = s.New()

[pjmlp]

Just as additional info to others, this is how Ada, Modula-2 and Modula-3 generics kind of work.

[nickcw]

I think parameterized packages are a great idea. It would be a light-weight way of getting just a bit of generic code into go.

I made gotemplate to explore that idea

https://github.com/ncw/gotemplate

This requires a round of `go generate` for the actual code generation, but otherwise quite a similar experience.

Having it built in would be great!

[polymathist]

Parameterized packages are interesting but they come with their own problems. It can get tedious if I want to use, e.g., a stack with multiple different types. They also lose some of the flexibility that comes with scoping type parameters to any function/method/data structure.

[bakul]

On the other hand writing such packages becomes easier as only two syntax extensions are needed (package header and import). You can easily abstract a package by replacing a concrete type with a package level parameter. More importantly, there is no other mechanism to tie together a bunch of objects, functions, methods etc. to the same parameter types.

[weberc2]

I’ve seen this in ocaml and always thought it strange. I think it’s useful, but binding it to a package seems odd since packages are units of code distribution or some such.

[pjmlp]

It is not strange if you think of objects in OOP as modules/packages you can inherit from.

[bakul]

Think of it as a package macro.