3 ms·
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
by mopsy 9y 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.
- bsaul 9y agoi'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).
- mopsy 9y agoWell, 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?
- Someone 9y agoI 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.
- GauntletWizard 9y agoGo 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}
- Someone 9y agoThanks. 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.
- nickcw 9y agoThat is pretty much exactly what my gotemplate package does, except using go generate... https://github.com/ncw/gotemplate https://github.com/ncw/gotemplate