zig fmt: tabs for indentation, spaces for alignment

[sengir]

The proposal #17145 seems to be hinged on the idea that we're leaning entirely on zig fmt and giving up manually formatting our code. After all, who in their right mind would manually align everything outside of niche cases like giant switch cases or array literals? I don't mind this (I personally use format-on-save), but this opens the floodgates to other zig fmt changes that "no human ... is capable of handling ... correctly." Specifically, I'm referring to "tabs for indentation, spaces for alignment" AKA "smart tabs" which has previously been dismissed for being unfeasible for mere mortal developers to correctly type.

The indentation war is a stale meme; Zig has long decided on spaces for indentation. However, just as #17145 suggests shedding longstanding practicalities rooted in the status quo in favor of forward-thinking improvements, smart tabs are in the same boat. Smart tabs appear identical to space indentation to 99% of viewers and would have little to no impact on their workflow, but by using exclusively tabs for indentation and spaces for alignment, visually impaired (or otherwise differently opined) developers can configure their editor to use their preferred indentation width without misaligning any intentionally aligned text or needing to constantly reformat their code between zig fmt and their more visually accessible style. This is a proven style that JetBrains IDEs have offered for many years.

The FAQ wiki page has a section on this matter in favor of "tabs for indentation, spaces for alignment":

Because no human and no contemporary code editor is capable of handling tabs correctly. Humans tend to mix tabs and spaces on accident, and editors don't have a way to "indent with tabs, align with spaces" without pressing the space bar many times, leading programmers to use tabs for alignment as well as indentation.

Tabs would be better than spaces for indentation because they take up fewer bytes. But in practice, what ends up happening is incorrectly mixed tabs and spaces. In order to simplify everything, tabs are not allowed. Spaces are necessary; we can't ban spaces. But tabs are not strictly needed, so the null hypothesis is to not have them.

Maybe someday, we'll switch to tabs for indentation, spaces for alignment and make it a compile error if they are incorrectly mixed. But if we did that today, writing Zig code would be too hard. For now your options are to configure your editor to insert spaces when you press the tab key, or configure your editor run zig fmt on save (recommended).

Currently, the stage1 parser rejects tabs and the stage2 parser accepts them. What will make it into the final language specification? It isn't decided yet and it doesn't really matter. Just run zig fmt on save.

Writings on the matter:

1. https://dmitryfrank.com/articles/indent_with_tabs_align_with_spaces
2. http://lb-stuff.com/tabs
3. https://old.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/

Of course, the real icing on the cake is pissing off both tab purists and space purists with an objectively richer (and more accessible!) alternative.

[mk12]

I find in these debates people often assume that tabs-for-indentation implies tabs only occur at the start of lines. But that's not true: you can comment out code, or have code examples in doc comments, or put code in strings, and now you have mixed tabs in the middle of the line. In particular the tabs might not start on an tab-width boundary, resulting in weird indentation. I notice this in Go and it annoys me.

[karlseguin]

FWIW, I use a pretty large font and as the years go by, it only gets larger. I don't have a disability, but my eyesight isn't great, and I do have underlying eye health issues. Tabs are objectively more accessible. I believe this proposal is aligned with Zig's own code of conduct, which doesn't speak directly about accessibility, but has a few relevant points, including Showing empathy towards other.

[andrewrk]

I don't buy the accessibility argument.

To be clear, I think empathy towards those with weaker eyesight is certainly warranted, however, let's try to analyze the problem like engineers. A programming language's job is to give semantic meaning to a source file. If a programming language led to ambiguity about whether something is indented or not, or whether it is a keyword or a function, that would be a problem for accessibility. It's why we care about the semantic web so much. In web pages it doesn't matter for accessibility purposes how much indentation is in the HTML; it matters what is semantically communicated via that HTML.

Now, I think it is totally fair to argue something like, "I don't care about in theory how it should work, I care about results. Just make it better for people who have trouble seeing." Now that's an attitude I really identify with. However, no matter which angle we look at it from, this one, or the previous paragraph, the accessibility villain is clear: the text editor.

It is trivial to know what is indentation in a source code file, especially in Zig. Text editors are already the ones providing the font size options, and it's absurd that they are not also providing the indentation size. Furthermore, in languages that tabs are used, you always find an incorrect mixture of tabs and spaces in real world projects. This actually serves to make detection of indentation buggier, harming the text editor's ability to control indentation size.

So, please redirect this accessibility shaming at your text editor - the app that you are literally looking at.

[Steelsmasher]

If a programming language led to ambiguity about whether something is indented or not, or whether it is a keyword or a function, that would be a problem for accessibility.

@sengir's proposal is to use tabs for indentation and spaces for alignment. This would mean there is no ambiguity over whether something is indented or not.

"I don't care about in theory how it should work, I care about results. Just make it better for people who have trouble seeing." Now that's an attitude I really identify with.

Ok so would you agree that in "theory" text editors should provide options for indentation size, but in reality many don't? Therefore if Zig is taking responsibility for readability (which is an inseperable part of accesibility) then it is only right that it picks a form that is most accesible. For which @sengir makes a strong case for it to be Smart Tabs.

[andrewrk]

Duplicate of #544. I don't want to hear any more people's opinions. I think that has been made clear by locking the topic, even though I have been baited into the discussion yet again. I have all the information, every point that can possibly been made has been made. This topic is the bikeshed of all bikesheds, and as the BDFN I get to choose the color.

I reserve the right to change my mind on this topic before 1.0.