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