I think the whole point of picking a language standard is to prevent the "space vs tabs" debate. Andrew is trying to standardize the language formatting issues, similar to tools like `rust fmt`, `gofmt` and `black`.
The "Spaces vs. Tabs" argument shouldn't be what stops you from joining hands and working together :)
I completely agree with you, I love not caring about formatting anymore. That being said, does this mean that zig refuses to compile code containing tabs? Because that seems a bit counterproductive to me.
A great advantage of rustfmt and friends is that I don't really have to care about my editor being correctly configured, I can just code without worrying about style and run rustfmt before comitting. But if the compiler outright rejects poorly formatted code it means that I have to run the format tool every time I want to compile or risk having my code rejected due to format issues. Now I have to care about my style again! It's the opposite of what I want.
I mean it's a very small issue and mainly a bikeshed, but that seems like an odd decision to me.
You have a valid point, but if the only formatting issue you will have is tabs, then running `zig fmt` on your codebase is pretty much a non-issue.
If your project is small, just run `zig fmt` on the command line.
If you have a large codebase, you can just incorporate it into your build process (similar to how clang-format and clang-tidy are used in CMake projects).
But again, if you have a large codebase written in Zig, you've probably already configured your editor to run `zig fmt` on save :)
“Refuse to compile” makes it sound like the compiler is able to but unwilling to compile the code. It could very well be that the parser doesn’t recognize tab as a valid token.
The "Spaces vs. Tabs" argument shouldn't be what stops you from joining hands and working together :)