This topic and Std scope seem connected.
Maybe worth discussing together.
1 Like
Split std into core and extensions.
Keep core small and stable.
Extensions are developed by contributors.
3 Likes
Could be a good approach.
Since last year, I have developed my own standard library because I take issue with the std and how it’s structured. Actually this is probably something I want to write about.
This is really not what I had in mind.
But I remark it’s way easier to contribute to Zig translate-c which has clear scope and ownership (Vexu).
One thing which is hard with contributing to Zig core, is the blast radius of any change. When I work on PR, I’m often surprised by the magnitude of changes on random target: your change broke windows-x32 platform, or more recently broke our lldb fork.
But pre-1.0 maybe having alternatives std may actually be good for the language, allowing to test more ideas, and consolidate later in official std.
3 Likes
Yeah I think this does have some values, std could be the stable core, minimal and restricted to trusted contributors, with specific issues, and then the contrib std would be the one where stability is not a guarantee, it’s a place where you can get a lot more high/low level.
And hopefully it can help in the long run to curate and maintain by the community and by more contributors a healthy battery included std. I don’t mind getting a few packages here and there, but I’d much prefer to have a special std, with the kitchen sink, things for doing vec math, http, MOQ, toml parsing, idk, it could be a great place to consolidate individual’s effort into one place.
Looking at the state of the ecosystem, there’s already a lot, but often you’ll find great packages that are abandoned, which is a shame because this means that everyone basically has to make a fork, and fix the current issues before using it, and upstreaming the changes doesn’t guarantee that it will be merged, whereas if all those great packages were in one place, it would be easier for anyone to upstream changes, and for a few contributors to maintain it when they can. It would also unburden core maintainers from having to maintain an std which is basically a byproduct of compiler’s need when the compiler is a moving target itself.
They wouldn’t need to care about breaking changed anymore, or to be more precise changing the std, because the compiler requires it, wouldn’t cause so much mayhem if those 2 were separated.