5 ms·
> Everything in Zig is const x = blah;, so why are functions not const bar = function() {};? This may or may not happen: https://github.com/ziglang/zig/issues
by dnautics 5y ago
> Everything in Zig is const x = blah;, so why are functions not const bar = function() {};?
This may or may not happen: https://github.com/ziglang/zig/issues/8383 https://github.com/ziglang/zig/issues/8383
> Fixing the standard library documentation would be my biggest priority if I worked on Zig, because I think that is the only thing holding back general usage of the toolchain.
This is a valid concern, but I believe the zig team is deliberately holding off on improving the std lib documentation, because they are expecting (potentially huge, maybe not? who knows) breaking changes down the line. The "stdlib is not documented" is a deliberate choice to signal "use at your own risk, especially with respect to forwards compatibility".
> there are still quite a few bits of syntatic sugar hiding the real cost of certain operations (like the try error handling, there is implicit branches everywhere when you use that...
I dunno, that's like saying that `if` hides branching. It's a language-level reserved word, you're expected to understand how they work under the hood.
- ArtixFox 5y agoyes, our first priority is stage2, after that, we might deal with stdlib. Andrew is going to go through the stdlib before the 1.0 release.
- dnautics 5y agoit's super reasonable to expect language-level stability before shoring up the stdlib. I know 'gatekeeping' is a bad word sometimes here, but this is soft-gatekeeping, and imo, a good thing (for now) to help focus the language.
- ArtixFox 5y agounfortunately yes, it somewhat is, but the devs try to maintain extremely readable source, not the best thing but i think its really good and important cuz its the best example of good zig code and might teach you a bit or two like i learnt how to write saner and better code. and the stdlib breaks sometimes soo its better to not put a loot of effort in docs