A couple weeks ago there was long thread about the poor state of Zig documentation. The OP suggested creating a wiki where the community can help out. I suggested that a public Git repo is a better option based on the stronger sense of the permanence and also greater convenience.
I have gone ahead and created such a repo at Codeberg. In the project wiki page, you’ll find a description of the idea behind the project and some basic guidelines.
I’ve created pages for builtin functions so far. The repo is sort of usable. You can clone it and stick in your workspace and see for yourselves if it’s a convenient way of looking up information.
Let me know what you think and if you’re interested in helping out. The bootstrap phase of the project involves mainly copy-and-pasting. You won’t need to put in a huge amount of time to make a difference. A few minutes a week across multiple people will add up. The key thing is to get the ball rolling.
A few random comments based on what I see. Take them to be worth what you paid for them
One of the best things this project could do is add working simple but useful examples. For sustainability, it needs a way to pull these examples from working buildable code with a CI process so that breakage is instantly detectable. Such a process would have prevented the typo in the @popcount page’s code (“vector” is misspelled).
There will need to be branching/tagging organization to capture Zig version specifics, and a guide for contributors for using that system correctly.
I looked at @popcount, and I’ve always curious what are the actual use cases for this and similar primitive. The info so far didn’t help with motivation for the builtin’s existence.
I looked at one that mentions a builtin working with “vectors”, but this term is ambiguous and I think is specific to @vector types, not general “vector-ish” things that people bring their previous expectations to. Docs like this need to be precise in terminology, and hence there is a place for a glossary of terms.
