I’m interested in exploring Zig, but the draconian measure to ban hard tabs is pushing me (and many others from what I’ve read online) away from it. Andrew, get off your high horse, allow hard tabs, and we can all join hands and work together.
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.
If tabbed indetation not being supported by the stage1 compiler is enough of a reason to not use a language it's probably best for zig to avoid those that would make this type of feedback and vice versa until stage2 and the language are stable (both support tab indentation, they just aren't finished).
I'm solidly in the tabs camp myself I just understand bikeshedding about this class of issue isn't what zig wants to/should be worrying about at the moment while core components are still being shifted around and written. In the meantime "zig fmt" runs as part of my build and life moves on.
I used to fight about prettier (js) gofmt and so on. I just finally found I don't care. It's more fun to just code and watch it all get autoformatted to the project or language standard
The reason hard tab people dislike code editors which convert to spaces is that pressing backspaces during editing removes one space, not all auto-inserted spaces. This ends up being very frustrating (since you need to press backspace 4 times). Most “used” languages allow both. Accept tab as another white space character and life goes on. Compile errors for hard tabs is a stubborn decision.
> The reason hard tab people dislike code editors which convert to spaces is that pressing backspaces during editing removes one space, not all auto-inserted spaces
This is simply not the case for any editor I have used recently.
Any editor worth it's salt will indent with tab and de-indent with shift tab with the cursor at the first non whitespace. Any good editor will de-indent with the cursor anywhere on the line.
