Proposals for generic maps and container/set packages

317 views
Skip to first unread message

Ian Lance Taylor

unread,
Jul 21, 2021, 7:42:58 PM7/21/21
to golang-dev
I've started discussions for generic maps and set packages. The
intention is that the discussions will become formal proposals.

https://golang.org/issue/47330 (maps)
https://golang.org/issue/47331 (container/set)

Ian

Sebastien Binet

unread,
Jul 22, 2021, 3:14:41 PM7/22/21
to Ian Lance Taylor, golang-dev
Apologies if it isn't the best place to discuss this "meta issue", but, what's the rationale for putting slice-related types and funcs under 'slices', map-related under 'maps' but set-related under 'container/set' ?

For discoverablity, wouldn't it be better to enforce a single naming convention for the location of these container related packages?

Cheers,
-s

Jul 22, 2021 01:42:55 Ian Lance Taylor <ia...@golang.org>:
> --
> You received this message because you are subscribed to the Google Groups "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAOyqgcXkgyLsJdHAdcTfu5nwLYytgEuTHQGSF6GFM-pTWAS-8A%40mail.gmail.com.

Ian Lance Taylor

unread,
Jul 22, 2021, 3:34:45 PM7/22/21
to Sebastien Binet, golang-dev
On Thu, Jul 22, 2021 at 12:04 AM Sebastien Binet <s...@sbinet.org> wrote:
>
> Apologies if it isn't the best place to discuss this "meta issue", but, what's the rationale for putting slice-related types and funcs under 'slices', map-related under 'maps' but set-related under 'container/set' ?
>
> For discoverablity, wouldn't it be better to enforce a single naming convention for the location of these container related packages?

Slices and maps are types that are part of the language. The proposed
slices and maps packages provide functions (not methods) that permit
using slices and maps of arbitrary element types. The set package, on
the other hand, defines a (generic) type that supports a set of
elements. It provides mostly methods on that type, along with a few
helper functions. So maps and container/set feel different to me.

We could of course go a different route, and define a top-level sets
package that is a lot like the maps package, but works with maps whose
value type is struct{}, and includes functions for operations that are
built-in for maps (such as indexing and assignment). I've tried it
both ways and personally I prefer container/set, so that is what I
proposed. I'm open to counter-arguments.

Ian
Reply all
Reply to author
Forward
0 new messages