proposal: decide what to do about existing container/* packages

[earthboundkid]

With type parameters coming in Go 1.18, the question of how to adapt existing standard library packages is becoming pressing. In particular, type parameters are designed to allow for generic container types, so one wonders what to do with existing standard library containers. It's probably best to let 1.18 out the door before making final decisions about exactly what to add or deprecate, but OTOH, there should probably also be a framework for decision making. I don't see another issue or discussion for the general topic, so I'm opening one.

Compare #47619 (generic sort) and #47632 (generic heap).

---

My personal preference is:

• Deprecate container/list and container/ring
• Add generic container/set (proposal: container/set: new package to provide a generic set type (discussion) #47331) and container/deque
• Add a generic slice based implementation to container/heap

But I could be talked into something else.

[fzipp]

Deprecate container/list and container/ring

None of the currently proposed generic packages provide the functionality of these two packages.
Also, I'm not sure if anything needs to be deprecated just because shinier generic variants exist. The non-generic types and functions still work.

[earthboundkid]

My reasoning for deprecating container/list is that it should be replaced by container/deque, since deques have better performance than linked lists in pretty much any plausible scenario. I guess you could add a generic version to container/list and then add a comment at the top suggesting that users probably actually want a deque, but it seems more straightforward to just deprecate it.

Ring I have never wanted to use. I could be convinced that it's useful, but it seems sort of esoteric, to be honest. A ring buffer, for example, is much more obviously useful than a linked list ring, but it's not in the standard library.

[earthboundkid]

A quick search on SourceGraph for "container/list (not file:vendor) lang:go count:all" vs "container/ring (not file:vendor) lang:go count:all" shows 5.3k results vs 1.9k results. Seems like there's probably a case for making a generic version of ring, even if it's not as popular. I still don't see much use for list though. Just replace it with deque.

[robpike]

It seems likely that list is unused because slices cover most cases where other languages might use a list. I suspect the same applies comparing deques to lists.

[earthboundkid]

Slices make it very easy to push and pop from the tail, but pushing to the tail while popping from the head (a queue) is still sort of cumbersome, which makes using a deque worthwhile.

[mdempsky]

We can't "decide" what to do with the packages without some concrete proposal about what to actually do to them; and then having such proposals, naturally part of the proposal process is to decide on them. I don't see any tangible outcome that would result from either accepting or rejecting this proposal?

[earthboundkid]

Closing for #48287.