Consider switching to tab-based indenting in new Rust edition

[clarfonthey]

Right now, Rust's standard formatting suggestion is four-space indentations. However, there are multiple reasons why tabs may be more accessible, including:

• Some (potentially common) screen-reader configurations may read out multiple spaces instead of as individual units
• Tabs are easily configurable for folks who need larger or smaller indentations for a variety of reasons
• Probably others I haven't thought of

There already are standard ways (e.g. editorconfig) to make tabs display as a set number of spaces in editors, and switching to using tabs by default would improve the accessibility of Rust as a whole. So, we could still set a recommended size for tabs to be displayed as four spaces, while still preferring the use of tab characters in files.

Note that this would simply be the default suggestion, and folks can still use spaces if they prefer. And because of the stability guarantees of rustfmt, it would have to be done with an edition bump, which is potentially coming up in 2021.

One of the biggest arguments against using spaces instead of tabs is the ability to do visual alignment, which is actually suggested against in the default Rust guidelines. Since Rust is already essentially using four spaces in the same way as tab characters, I think it would make sense to switch to tabs as a whole for continuing one of Rust's core goals of accessibility.

Note: as clarified in a few comments here, whatever happens should be the result of working with folks who use assistive technology (screen readers, braille readers, font scaling, etc.) and seeing what is most accessible to them. However, I have a feeling that tabs will ultimately win out as they're much more easily configurable. The whole point is to heavily consider the option of switching to tabs, not simply assume that either that solution or the status quo is best for everyone.

[Lokathor]

If we recommend tabs there's no value to be had in suggesting tabs be displayed as a specific size.

[clarfonthey]

If we recommend tabs there's no value to be had in suggesting tabs be displayed as a specific size.

I think there would be, considering how we have tools like rustdoc which will render tabs at a certain size. It would make sense to standardise that. Plus, there could be value in cargo init adding an .editorconfig file.

[BurntSushi]

Unfortunately, this is not very accessible for folks who use screen readers, since individual spaces have to be read out instead of a single tab.

Are there any experience reports from folks that use screen readers that conclude this? I recall seeing one that counter intuitively came to the opposite conclusion, but I can't remember where.

[aloucks]

I sympathize with the @clarfonthey's use case, but tabs in code are a never ending source of inconsistent rendering behavior. For example, C++ files sometimes render poorly in github due to the prevalence of tabs. I would hate to see Rust follow this route.

Are there any other options for folks using screen readers without regressing to using tabs?

[clarfonthey]

Unfortunately, this is not very accessible for folks who use screen readers, since individual spaces have to be read out instead of a single tab.

Are there any experience reports from folks that use screen readers that conclude this? I recall seeing one that counter intuitively came to the opposite conclusion, but I can't remember where.

I know that newer IDEs like vscode are adding better support for space-based indenting, but this relies on the indenting working as expected. Simple typos like using three spaces instead of four while editing can result in the spaces still being read out. I personally have worked with a coworker around ~3 years ago who said this was the case, but even then, you can't expect every editor to work properly with these cases.

The most well known post about this is probably this one on Reddit where some visually impaired folks mentioned the ability to override display width in their editors was also a reason it's more accessible: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/

So, using just screen readers as an example is probably underselling it, since that has workarounds.

[clarfonthey]

I sympathize with the @clarfonthey's use case, but tabs in code are a never ending source of inconsistent rendering behavior. For example, C++ files sometimes render poorly in github due to the prevalence of tabs. I would hate to see Rust follow this route.

Are there any other options for folks using screen readers without regressing to using tabs?

Inconsistency in rendering in these cases is also an accessibility issue that needs to be fixed in renderers rather than just falling back to spaces. You're putting your desire for aesthetics as a well-sighted person over the desire for usability of a vision-impaired person, which is not the right approach.

Granted, tabs may not be the solution here and spaces may win out for accessibility (I personally doubt it) but this is very much the wrong lens to view this under IMHO.

Something, something, the curb cut effect, also.

[skade]

Unfortunately, this is not very accessible for folks who use screen readers, since individual spaces have to be read out instead of a single tab.

Are there any experience reports from folks that use screen readers that conclude this? I recall seeing one that counter intuitively came to the opposite conclusion, but I can't remember where.

You might think of this comment, pointing out that the comment syntax is very accessible for users of braille reader displays, which are far more common in Europe: rust-lang/style-team#120 (comment)

So, essentially the problem is: changes around this should only be done if multiple people from the same affected group, using a variety of accessiblity methods have concluded this is a bad thing. Otherwise we run into the danger of accidentally following someones personal preference or ignoring that people use a number of different tools to solve the same problem. This problem gets harder due to the fact that usage of assistive technology is widely differing across the globe, because of differences in the healthcare system or just plain availability. As a project of global scope, we need to think along those dimension. A change like this is substantial, so it has to weighted.

Just to be clear: I'm not trying to push the problem away, but it's a common effect that abled people take the first voice they hear, generalise it and then pass this off as "we asked disabled people".

[clarfonthey]

Couldn't have put it better @skade and I also updated the original post to clarify a few things re: what you said. <3

[LoganDark]

As far as I've heard, the only purpose of spaces is to force the indentation to look exactly the same regardless of where it is viewed. They are nothing but a visual tool, and the point is to make the indentation immutable. Any other argument can be shot down in seconds (file size, editor support, semantics, accessibility, flexibility, etc.). It looks like the screen reader issues are a side effect of this.

The nature of the tabs vs spaces debate is always extremely opinionated. I agree that tabs are a better solution, and have even managed to change some minds in the past. I particularly like the fact that one tab always equals one indent, and indentation can be differentiated from alignment (which would still use spaces).

Here's an example of using spaces for alignment (where → is a hard tab and · is a space):

fn main() {
→   let·x·=·f(arg1,
→   ··········arg2,
→   ··········arg3);
}

I believe that's called a hanging indent, but don't quote me on that. There's also "smart indent", which uses both tabs and spaces to combine units of indentation with character alignment:

fn main() {
→   let·x·=·f(
→   →   ········arg1,
→   →   ········arg2,
→   →   ········arg3
→   ········);
}

Although, in my opinion, that looks kind of silly and wastes space. Imagine if the variable name were longer, or the function name. I personally use the "continuation indent" style, which doesn't align:

fn main() {
→   let·x·=·f(
→   →   arg1,
→   →   arg2,
→   →   arg3
→   );
}

With spaces, you are always aligning based on characters rather than indentation levels. It's a subtle difference, but I prefer to use units of indentation for indentation, and leave the character alignment to the tool displaying that code visually to the user. This also makes it easier for non-visual tools to parse indentation, such as screen readers.

[jyn514]

I'd like to bring up the absolutely staggering amount of churn this would cause. Imagine that you switch to Rust 2021 (or whatever edition) and run rustfmt - almost every single line of code in your codebase would be changed. There is the alternative to write a rustfmt.toml that explicitly asks for spaces, but that itself is churn, although much less of it. I don't see any major projects switching to tab-based indents just because rustfmt changed its defaults.

Is the benefit for new projects really worth all the noise it would cause for existing ones?

[LoganDark]

Is the benefit for new projects really worth all the noise it would cause for existing ones?

Yes.

[clarfonthey]

Is the benefit for new projects really worth all the noise it would cause for existing ones?

Again, you need to frame this from the perspective of accessibility. The benefit is that people who need it can now interact with your code without needing to perform additional modifications or use additional tools. The cost is a single commit which changes your indenting.

And again, this wouldn't be a sudden, unannounced change; it would come with a new edition, where you explicitly choose to use the newer edition over the old one.

Imagine a similar scenario where one entrance to a building is closed so that they can add a ramp. You could argue that, since most people don't use wheelchairs, this is unnecessary churn. But that'd be pretty rude to wheelchair users.

The only question we should be asking IMHO is to what extent this helps existing users, and if it makes the code more accessible. The effort to switch is a non-issue IMHO because of all the things I've mentioned here.

[LoganDark]

Not to mention the non-accessibility benefits that tabs have over spaces (see my post above). It may be difficult for some projects to switch, but they'll be better off in the long run. And, of course, some will stay on spaces.

[calebcartwright]

I'd like to bring up the absolutely staggering amount of churn this would cause

I think this is a really important point, and why I'm opposed to changing the default (regardless of what the value is). Independent of the merits/drawbacks of the two options, this proposal would be highly disruptive and impactful, particularly in larger/active projects, and I feel like there'd need to be an overwhelming super-majority agreement from the community to make such a breaking change. I do not get the sense that there's a majority consensus (much less an overwhelming one), and I'd suggest that's at least anecdotally supported by the reactions/comments on this thread.

I know this is a rather evocative topic that people feel very passionately about. I also believe the vast majority of folks are firmly entrenched in their respective camp convinced beyond a shadow of a doubt that theirs is the "right" answer and don't understand how anyone could disagree. Just remember though that most of those on the other side feel exactly the same, and very, very few can be convinced otherwise.

This topic has been debated at length, and I think the final conclusion from the original RFC is still a good summary:

Thanks all for the discussion here. With regards to tabs vs spaces, the matter is settled - there is pretty strong (though obviously not unanimous) consensus in the Rust community in favour of spaces, and we've discussed here the objective benefits of the two approaches, as best we can. I firmly believe that at this point there is no possibility of changing this decision, so it's not really worth discussing further.

To summarise:

* the style guide will recommend using spaces and not tabs,

* Rustfmt will use spaces by default,

* **Rustfmt will continue to support tabs as an option**, so if you are a tabs supporter you will still be able to use Rustfmt, just with some minimal configuration.

Yes accessibility is important and yes accessibility and the other pro-tab points mentioned on this thread were part of the discussions as the Style Guide was being codified, but ultimately the decision was made to default to spaces based on other factors and feedback.

IMO the fact that that default has now been in place for several years only makes it that much more difficult to reverse that decision. The incumbency advantage/status-quo bias do weigh heavily, and I feel like the calculus behind the original decision would have to have shifted dramatically to override both the original (and oft re-affirmed) conclusion and the subsequent now long-established status quo.

Based on my experience working with rustfmt and the Style Guide, I have not gotten the impression that the majority position of the community has changed.

[comex]

Again, you need to frame this from the perspective of accessibility. The benefit is that people who need it can now interact with your code without needing to perform additional modifications or use additional tools.

There is a serious dearth of evidence that this is actually true.

I particularly like the fact that one tab always equals one indent, and indentation can be differentiated from alignment (which would still use spaces).

I agree that combining tabs for indentation and spaces for alignment would be great in theory. In practice, though, many editors lack even the most basic support for mixed tabs and spaces, at least out of the box.

For example, try creating a file like this, but where <<TAB!>> is replaced with a tab character:

fn foo() {
<<TAB!>>xxxxxxx(one,
<<TAB!>>        two,
<<TAB!>>        three);
}

The above is assuming a tab width of 8; for editors that default to tab width 4, make the function name shorter. The idea is that the line containing two starts with one tab (for indentation), followed by a number of spaces that happens to be equal to the tab width (to align after the opening paren).

Then go to the end of the line containing two and press enter. The editor should automatically indent the next line to match. But will it reproduce the same mix of tabs and spaces, or will it convert the spaces to a tab?

I tested Vim, Emacs, VS Code, and IntelliJ IDEA under default settings (except for enabling automatic indenting in Vim, which has it off by default).

• IDEA did the right thing by default.

• Vim and Emacs did the wrong thing by default, but can be configured to do the right thing:

  • Vim has an option to fix this (but more advanced functionality like auto-alignment doesn't work).
  • Emacs has a downloadable package (that apparently does support smart auto-alignment).

  Still, most Vim and Emacs users probably don't have their editors configured that way and would have to learn how to do so.

• VS Code did the wrong thing and I don't think there's any solution ([1] [2]).

Other editors, with smaller userbases and fewer features, are also likely to lack support. For example, GitHub's web-based editor does the wrong thing and, having only minimal configuration options, can't be configured to do the right thing.

You might argue that people should just rely on rustfmt to fix their indentation. But even if you do, it's going to cause problems if your editor is constantly butchering the indentation as you edit. Besides, some people prefer not to use rustfmt.