Re:Zig is becoming more production-worthy
by ihateolives on Tuesday July 05, 2022 @08:05AM
(#31987183)
Having to build your own version of the compiler to fix this annoyance is like using a sledgehammer to crack a nut. It should be a simple flag, whichever way the default, but it shouldn't require building a compiler.
That's nuts, both in a bad and a good way.
Re:Zig is becoming more production-worthy
by chienandalou on Tuesday July 05, 2022 @10:17AM
(#31988444)
I agree, it should be a flag. Or it should be a warning in debug builds, and an error in release builds.
I'm not sure it's nuts to build the compiler to 'fix' this, though. Customizing and building a tool really isn't such a big deal when you think about it.
Re:Zig is becoming more production-worthy
by anonymoushn on Tuesday July 05, 2022 @09:39AM
(#31988076)
I have my own version of the stdlib because I don't think formatting a number with leading zeroes should involve parsing UTF-8. It's pretty easy!
I once said I would like arrays of 33 or more items to be Default and my resident Rustacean told me step 1 is to rebuild libcore after changing the appropriate macro :)
That funny. I have one where octal is banned.
Re:Zig is becoming more production-worthy
by delphLonepaw on Sunday July 17, 2022 @03:47AM
(#32125162)
I think the unused error is great, and a lot of people once they got used to it, it becomes quite the useful message, some bugs and some mistakes not easy to catch are quite there now.
Giving it a bit of time is a good way to get used to it and ends generally (at least in my opinion) in better code.
Outside that :shrug:
I use this method to build a zig compiler to work with, and when I build a release build of my zig-project I switch to the official compiler and fix the handful 'unused variable' errors. Works fine for me.