[Vendan]

That's... slightly better, but afaict, "allows both spaces and tabs" seems to be "convert tabs to spaces"

    zig fmt accepts and converts tabs to spaces, \r\n to \n, as well as many other transformations of non-canonical to canonical style.

Which is... still saying "spaces instead of tabs"

[zamadatix]

"zig fmt" is the formatter not the aforementioned self hosted compiler.

[Vendan]

It's a part of the ecosystem, and is, AFAICT, saying "tabs are not welcome here". Happy to be proven wrong.

[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"