We can use std.HashMap with the Key=<your set element type> and Value=void, but seems hacky: the API isn’t as good as it could be e.g. you have to treat keys as your values and disregard a big part of the API.
This issue exists, but was closed without comment.
Does anyone know why std does not / cannot have HashSet? Wondering if there’s a good reason I’m not seeing
It’s not worth the maintenance burden when you can just use the aforementioned std.HashMap(T, void). It’d surely just be implemented as a weird API-reducing wrapper around it anyway. Zig doesn’t really do abstractions just for the sake of doing abstractions.
4 Likes
I agree the lack of a proper hash set is a bit annoying, but like mentioned before std.HashMap(T, void) works. But it could eventually land, there’s an issue on github, which details that the plan is to first finish the language, stabilize it, offer tier 1 support for more targets, and then focus on auditing the std, to improve it.
Right now the std is in a weird position, in the sense that it’s essentially a byproduct of the compiler’s need (although really well designed IMO and thoughtfully written API). I don’t know if they have decided on a strategy for the std (aka batteries included or basic building blocks only).
So it’s impossible to know what the future will offer, but essentially it could go both ways and something like a proper hashset could live in the std. Or not at all, right now it’s probably best to copy/paste the std.hashmap rework it into a proper hashset, put it on github as a package and use it this way.
3 Likes
std.AutoArrayHashMapUnamanaged might be slightly better than std.HashMap, well in general not just for sets.
There’s also std.enums.EnumSet.
1 Like
Another example of this is std.PriorityQueue and std.PriorityDequeue - I think having one covers all the use cases of the other.
That’s true 