Because it would need generics

It could be a special-cased builtin like maps and slices and channels.

AFAIK the reason — much like C# — is their adherence to the concept of ubiquitous defaults / zero values: as far as Go is concerned all types have a zero-value (a non-overridable default value when not explicitly initalised), and as far as its community is concerned zero values are a good thing and must be embraced.

default zero is good, but default zero pointer... ugh

> default zero is good

Default zero without it being opt-in is terrible.

> but default zero pointer… ugh

That's what ubiquitous default zero gets you.

No it wouldn't. There are already built-in generic types like map[K]V and slices. If the Go Team wanted, they could easily add built-ins like option[T] and result[T]. But in Go 1.0 they would stand out like a sore thumb, because the stdlib wouldn't use them.

Maybe for Go 2.0.

I would like to see a set library as part of standard library if they are going to do something more on this front.

I would be more radical and add them as a part of the language, the way map is now. AFAIK, Wirthian languages like Pascal and Oberon all have sets as built-ins, with +, -, and * operators defined on them, and Go is heavily inspired by them.

It seems to me that's just a map[set_key]bool

1. because you can't build opaque abstractions in Go, you have to wonder if there's a difference between having a true and a false value mapped to a key

2. because sets are significantly less useful without set-operations (intersections, unions, differences) and since go does not have user-defined generics you can't build a generic version of those (

3. because it wastes 1 byte per item (according to the comments in bmap, buckets are implemented column-major

`map[K] struct{}` would fix 3 and the second half of 1 (struct{} is a zero-sized singleton) but is somewhat less ergonomic so the impact of what's left of 1 is worse, and it doesn't solve 2 at all