Skip to content

Commit

Permalink
caleb's applicable suggestions
Browse files Browse the repository at this point in the history
Co-authored-by: Caleb Cartwright <[email protected]>
  • Loading branch information
compiler-errors and calebcartwright committed Jul 5, 2023
1 parent 190db77 commit d66c255
Showing 1 changed file with 9 additions and 5 deletions.
14 changes: 9 additions & 5 deletions nightly-style-policy.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,22 +5,26 @@ new variants to AST representation), they should modify rustfmt in such a
way to keep existing formatting verbatim.

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

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

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

0 comments on commit d66c255

Please sign in to comment.