Skip to content

Commit d66c255

Browse files
caleb's applicable suggestions
Co-authored-by: Caleb Cartwright <calebcartwright@users.noreply.github.com>
1 parent 190db77 commit d66c255

File tree

1 file changed

+9
-5
lines changed

1 file changed

+9
-5
lines changed

nightly-style-policy.md

Lines changed: 9 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -5,22 +5,26 @@ new variants to AST representation), they should modify rustfmt in such a
55
way to keep existing formatting verbatim.
66

77
Rustfmt is allowed to implement nightly-only formatting behavior without that
8-
syntax being specified by the style guide. Initial PR implementors are
9-
encouraged but not required to open a PR against rustfmt suggesting an initial
8+
syntax being specified by the style guide. The initial authors of PRs
9+
implementing new features in rust-lang/rust are encouraged, but not
10+
required, to open a PR against
11+
[rustfmt](https://github.com/rust-lang/rustfmt) suggesting an initial
1012
formatting behavior, or formatting may later be implemented as a PR by anyone,
1113
pending approval of the implementation from T-rustfmt. T-style should be
1214
notified to approve the interim style proposed by these PRs, but this decision
1315
is not binding and may be revisited until the feature is stabilized and the
1416
formatting is codified in the style guide.
1517

16-
Much like breaking nightly feature changes in the Rust compiler, changes should
17-
be not done unnecessarily, and should take into account the feature's adoption
18+
Much like breaking nightly feature changes in the Rust compiler, any changes
19+
to formatting behavior for nightly syntax should be made cautiously and with
20+
thorough consideration to avoid churn. Changes should not be done unnecessarily,
21+
and should take into account the feature's adoption
1822
and readiness for stabilization. However, changes may be done until the feature
1923
is stabilized for various reasons: new understanding of the feature's usage in
2024
the language, recommendation from T-style, or changes in the implementation of
2125
the feature.
2226

2327
Feature stabilization should be blocked on confirmation and codification of
24-
formatting bheavior. At this point, T-style may also propose alternative
28+
formatting behavior. At this point, T-style may also propose alternative
2529
formatting at the time of stabilization, with any breaking changes weighted
2630
according to the principle stated above.

0 commit comments

Comments
 (0)