[lhorie]

See https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m...

In a nutshell, what you're currently using is the stage 1 compiler, aka the bootstrapping compiler to compile the official zig compiler going forward. zig fmt is opinionated because it was only meant to enforce formatting for the zig project. At that stage of the project's life, they felt it was more important to get shit done in a consistent manner w/ the people that are actually contributing than to cater to a hypothetical accessibility-impaired developer that isn't.

Zig is a very ambitious project. Prioritizing pragmatism over ideology is a fairly common theme with it currently. Another example: they repeatedly break stdlib APIs because catering to a larger audience is currently less important than getting other things nailed down first.

[Vendan]

I stand (partially) corrected, though everything there does still seem to point towards "tabs tolerated, but the formatter will convert to spaces". I also find it highly amusing that `zig fmt` converts tabs to spaces, and yet they point at gofmt, which, as far as I'm concerned, is the gold standard of "tabs for indentation, spaces for alignment." It could be that that is where zig wants to land eventually, and if so, I'm going to be quite happy and excited.

[lhorie]

I wouldn't read too much into what `zig fmt` means in terms of what is supposed to be idiomatic. Like many things in zig land, `zig fmt` isn't really mature yet - e.g. it still mis-formats things like long expression chains among other things. They are still planning to do a polish pass over all of these DX-related aspects of the project (fmt, stdlib). I'd expect this bikeshed to resurrect in full force once they start looking into zig fmt more seriously.

[zamadatix]

Using the built in formatter is optional, you'll be free to run your own formatter.

Right now you might be more worried about how the current compiler can't even compile Zig correctly before worrying about what stylistic choices it can handle. I'm a tabs guy myself but it's really quite irrelevant at the moment - the focus is still on figuring out how Zig should work and making that happen not day to day usability of the current toolsets for end users.

[Vendan]

Please see https://github.com/ziglang/zig/issues/544#issuecomment-36396... and https://github.com/ziglang/zig/issues/663. In particular, `For every codepoint of zig source code, it is an error for the codepoint to be one of U+0000-U+0009, U+000b-U+001f, U+007f, U+0085, U+2028, U+2029`. Hard tab is U+0009, which is called out as specifically an error. This could just be stale docs, but it's linked to from the wiki as well: https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-fmt-hav.... Again, if this is all old, please ignore (and maybe make it a priority to update?). But the general tone is: "No tabs, only spaces"

[zamadatix]

The first issue is closed with a nicely written message of how hard tabs will be supported and why they aren't now. The second issue links to the first issue when the point of hard tabs are brought up. The FAQ you link at the end contains, directly above the section you linked, a version of the explanation in the first issue, while the exact section you linked also links back to the first issue anyways.

So yes, all of the quotes and conclusions you found are either old or wrong according to the very pages you linked. No, it doesn't need to be updated (or prioritized?) as they all conclude with supporting tabs you just hadn't read all of what you're citing.

.

If there is still any doubt for some reason rather than trolling through GitHub issues from 2017 I'd recommend sticking to the current FAQ from 2021 which has a section dedicated to this question: https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m... as this is the fully current and authoritative answer on the status of tab support, regardless of where bits of past discussion lay on the matter.