I feel like keeping the data-structures in the same level as other types makes the standard library documentation a bit cumbersome to read. Has this already been considered before?
2 Likes
The docs literally has separate sections for types, functions, namespaces, and other declarations??
I know. I meant moving the data-structures to a namespace of their own, similar to the allocators in heap, instead of putting them in the top level together with Build, Io, Thread, etc.
It’s not really a docs thing, it’s more like the way the lib itself is organized. Maybe the way I phrased it wasn’t the clearest.
Just so others understand. Is your proposal to move things such as std.dataStructName, to something like std.dataStructures.name?
There has been lots of discussion about this but it’s not always easy to find. Here’s one example, starting with this post in a larger thread:
3 Likes
Something like that yes. My proposal is to move things like std.ArrayList, std.DoublyLinkedList, std.HashMap to a namespace like std.data_structure or std.ds.
Okay, but every type is a data structure. Clearly you have some criteria.
What is it, and why is it better?
Various things already have their own namespace, but common things are re-exported.
For example: std.ArrayList is a small wrapper for std.array_list.Aligned, that uses the default alignment for the item type since that’s very, very common.
There is std.ArrayListAligned which is just an alias for std.array_list.Aligned.
There is also the deprecated std.array_list.Managed which is not re-exported to discourage its use as it will be removed.
The array_list namespace mostly serves to separate all the array List specific tests.
Similar thing with std.hash_map.
If we take the reasonable gloss of “data structure” meaning “you can put data in it”, then no, this isn’t true.
std is a type, it is not a data structure. ArrayList is a data structure type. I call them “instantiable types” because it’s as clear as I can say it, but data structure ain’t bad.
I’ve said plenty already about how I’d prefer to see things organized, and “move all the data structures to std.data_structure” isn’t quite it.
But I do agree with OP that having a bunch of data structure types just hanging out directly off of std isn’t ideal, especially for new users.
1 Like
std is a type because zig uses types as namespaces and doesn’t have a non type alternative.
I think it’s reasonable to ignore such types in this discussion. I should have been clearer and said “instantiable types”.
I am not arguing against reorganising std, I just don’t understand Op’s criteria for what would go in there.
Per the Zig guidelines, by which zig std follows:
Everything is a value, all types are data, everything is context, all logic manages state. Nothing is communicated by using a word that applies to all types.
Every declaration is assigned a fully qualified namespace by the compiler, creating a tree structure. Choose names based on the fully-qualified namespace, and avoid redundant name segments.
Consider std.datastructures.ArrayList: ArrayList is already a data structure so the name is redundant. Reduced to std.ArrayList.
I think this rule is so solid that even with the 1.0 std rehauls, I expect those things to remain the same.
1 Like
Data structures, what we’re both calling “instantiable types”.
I too think the simpler ones, like ArrayList, the ones which don’t do double-duty as namespaces, should not be directly off std. I think that’s what OP is saying, except more specifically to move all of them into a single namespace container, which I don’t think is ideal.
For one thing, std is not the only namespace with data-structure / instantiable types in it. Which is good, I certainly wouldn’t want, idk, std.json.ObjectMap moved to std.data_structure, that doesn’t sound helpful either.
2 Likes
Yeah. I meant specifically the ones directly under std, other data-structures that already reside in a namespace or “fat-type” should stay where they are.
At the same time std.os exists despite being essentially just a category. That’s why I thought having a std.ds might not be unfeasible. std.heap and std.fs seem like they could also fall into this bucket maybe.
std.windows is not a great fully qualified name. Are we talking about doors, or sliding windows algorithms?
std.os.windows sounds like the most correct fully qualified name. And any OS names can be anything, so namespacing them in os is appropriate.
std.heap however is a relic of time and probably be rehaul before 1.0. std.fs I am not sure, probably it will be promoted to std.path. But are we considering PATH a separate thing in std? Then maybe std.fs.path is still needed.
This is why you should always take the name into account, not random “yes this thing is X so lets subclass / inherits X namespace” OOP-ish line of thinking.