Skip to content

Commit 84a6188

Browse files
committed
Add blog post for the Rust Style Team
1 parent e041f84 commit 84a6188

File tree

1 file changed

+61
-0
lines changed

1 file changed

+61
-0
lines changed
Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
---
2+
layout: post
3+
title: "Announcing the Rust Style Team"
4+
author: Josh Triplett
5+
team: The Rust Style Team <https://www.rust-lang.org/governance/teams/lang#Style team>
6+
---
7+
8+
Rust has a standardized style, and an implementation of that style in the
9+
`rustfmt` tool. The standardized style helps Rust developers feel comfortable
10+
and at home in many different projects, and the tooling support from `rustfmt`
11+
makes it easy to maintain and to incorporate in continuous integration.
12+
`rustfmt` also provides many options to customize the style, but the style
13+
guide defines the defaults, and most projects use those defaults.
14+
15+
The standard Rust style resulted from development and discussion within the
16+
Rust style team, between 2016 and 2018. After publishing the style guide, the
17+
Rust style team wound up its active work, by design.
18+
19+
However, as the Rust language develops, we have a regular need for improvements
20+
to the style guide, such as to support new language constructs. This includes
21+
minor language changes, as well as highly anticipated new features such as
22+
`let`-chaining (RFC 2497) and `let`-`else` (RFC 3137). New constructs like
23+
these, by default, get ignored and not formatted by rustfmt, and subsequently
24+
need formatting added. Some of this work has fallen to the rustfmt team in
25+
recent years, but the rustfmt team would prefer to implement style
26+
determinations made by another team rather than making such determinations
27+
itself.
28+
29+
In addition, rustfmt maintains backwards compatibility guarantees: code that
30+
has been correctly formatted with rustfmt won't get formatted differently with
31+
a future version of rustfmt. This avoids churn, and avoids creating CI failures
32+
when people use rustfmt to check style in CI. However, this also prevents
33+
evolving the Rust style to take community desires into account and improve
34+
formatting over time. rustfmt provides various configuration options to change
35+
its default formatting, and many of those options represent changes that many
36+
people in the community would like enabled by default.
37+
38+
For instance, many people prefer to format their `use` lines in three blocks:
39+
imports from the standard library, imports from external crates, and then
40+
imports from modules within the same project. `rustfmt` supports this via the
41+
option `group_imports = StdExternalCrate`, but cannot make this the default
42+
without causing CI failures in existing projects.
43+
44+
To solve both of these problems, [RFC
45+
3309](https://rust-lang.github.io/rfcs/3309-style-team.html) has revived the
46+
Rust style team, with three goals:
47+
48+
- Making determinations about styling for new Rust constructs
49+
- Evolving the existing Rust style
50+
- Defining mechanisms to evolve the Rust style while taking backwards
51+
compatibility into account, such as via Rust editions or similar mechanisms
52+
53+
We don't plan to make any earth-shattering style changes; the look and feel of
54+
Rust will remain largely the same. Evolutions to the default Rust style will
55+
largely consist of established `rustfmt` options people already widely enable,
56+
or would enable if they were stable.
57+
58+
We expect that the initial work of the style team will focus on clearing a
59+
backlog of new language constructs that lack formatting guidance. Afterwards,
60+
we look forward to introducing a few minor style evolutions in the Rust 2024
61+
edition.

0 commit comments

Comments
 (0)