go should support whatever stuff that could let me create a custom type safe container.
What is so hard to understand in that need ??
What is so hard to understand in that need ??
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.
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).
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?
import list "container/list" {Value: int}
import list "container/list" {Value: string}
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}
I.e.
import intlist "container/list" {Value: int}
import stringlist "container/list" {Value: string}So, this basically would boil down to something like C++ templates, with he extra requirement that templates must be instantiated explicitly.