Hacker News new | ask | show | jobs
by mopsy 3259 days ago
Because you should stop asking for generics like in Java/C#/rust etc.. Such generic to make custom type safe container is like using a canon to kill a fly.

You should ask for generic package/templated package. It solve the problem, it's way simpler and and would only touch a small part of the spec. More importantly, it wouldn't change the way we code in go today.

With generic package you only have to define the parameter in package declaration like this:

package list {Value: interface{}

And use it by importing it like this:

import list "container/list" {Value: int}

And that's why to go team asked for use case. To use the most simple tool to fix a problem so there is less chance for other problems to appear. If every people wanting to make custom type safe container would stop asking for full generics and instead would brought their case with a simpler solution. I'm sure it would have a chance to go in Go 2.0.

3 comments

I don't see how that would allow you to do both

  import list "container/list" {Value: int}
  import list "container/list" {Value: string}
in a single source file. At the least, you would need the ability to give the type(s) that those import statements import distinctive names.

Even that would, IMO, not be enough, as this seems (from what I infer the semantics to be) to make it impossible for writers of such a generic library to build on another generic library.

That can be fixed by allowing such a programmer to write:

  package foo {MyValue: interface{}}
  ...
  import list "container/list" {Value: MyValue}
but that, IMO, would be way too cumbersome. That package declaration would have to mention all types in all generic packages that get imported.
Go already allows you to rename imports. It's already used in the example provided, actually; the first token is the aliased name of the package.

I.e.

  import intlist "container/list" {Value: int}
  import stringlist "container/list" {Value: string}
Thanks. I didn't realize that the second token was a user-specified name.

So, this basically would boil down to something like C++ templates, with he extra requirement that templates must be instantiated explicitly.

That is pretty much exactly what my gotemplate package does, except using go generate...

https://github.com/ncw/gotemplate

i'm sorry, what in my post made you think i wouldn't be happy with your solution ?

i would even be happy with no generic at all if basic types implemented low level interfaces, and let me code my containers against things like "sortable, equatable, hashable" ( although it may pose other problems).

Well, It was more about strategy :) Sorry for the stupid analogy, but that's how I feel about the discussion:

A: I need a Ferrari to go to work. How is it hard to understand!

B: Well, you've only have 10 minute commute, a small car would do the work quite as well, as cost a lot less.

A: What made you think i wouldn't be happy with a smaller car?