###### tags: `proposals`

# Evolving rustfmt/style of nightly features

## Needs

* T-compiler's
* being able to format nightly features
* encouraging users to use new nightly features (broken formatting is discouraging) (also a t-lang need)
* T-rustfmt's
* Documentation and clarity for the rest of the organization

## Proposals

[...]

* ~~Initial implementation PR(s) allowed to, but not obligated to, implement formatting behavior for a new nightly surface syntax.~~
* Initial implementation PR(s) should generally leave rustfmt untouched, and are encouraged, but not required, to open a follow-up pr against rustfmt.
* Initial implementors may modify rustfmt to keep syntax verbatim, for example, to fix compiler errors in rustfmt that come from adding new AST nodes.
* Subsequently, anyone (though I expect typically either T-rustfmt or the owners of the compiler feature) is allowed to implement missing formatting for a feature, or tweak formatting for a nightly feature (given rustfmt approval of the code changes).
* We should take a similar stance to formatting stability as T-compiler does with feature gated nightly features; that is, formatting should not be churned unnecessarily. Subsequent changes to style should be justified.
* Changes are justified by, e.g., new understanding of the feature's usage in the language (e.g. new data suggesting that many users write short let-chains), or changes in the rust parser code (e.g. GATs' `where` clause changed position partway through their implementation).
* Care should be taken w.r.t. the wide-spreadness of feature's usage and closeness to stabilization.
* Eventual feature stabilization is blocked on confirmation and codification of existing formatting behavior if it is implemented, or proposal of a formatting behavior if one does not.
* T-style can propose an alternative formatting behavior if the current one is deemed insufficient at the time of stabilization.
* **FIXME**: This needs T-lang agreement?

## Discussion points

### "Flapping" formatting between stable/nightly rustfmts
* Should users of nightly syntax be advised to format their code using nightly rustfmt as well, even if it's `#[cfg(..)]`'d out? For example, if a project's formatting is gated on CI, then that CI should be using nightly rustfmt.
* Should rustfmt attempt to do nothing on stable (barring cases where it's impossible to detect that some AST is actually feature-gated or not?) for a new feature gate.
* For example, it's pretty clear that `dyn* Trait` is nightly syntax from just the AST, but `let x: impl Trait = ...` or let-chains is harder to detect since it requires context. That's why I'm thinking it could be advice, but not a requirement for rustfmt.

### Lifecycle of a feature
* T-style may agree to sign off on a nightly feature's style early in its lifecycle (or, conversely, should it be able to?) -- what happens if the ast representation/style implementation/etc. changes after that point? Can we de-stabilize a nightly feature's style guidelines, if it's not stable yet?
* Should we do a light T-style FCP on a PR that touches rustfmt introducing style changes?
* Something like "we as T-style are happy with users having this unstable formatting, and it's *believable* that this could be confirmed as the eventual style"
* Alternatively, something like a T-style "MCP", where somebody on T-style can sign-off?
* We still need to do a post-hoc confirmation of the style nearer to feature stabilization, but this is just for an initial soundness check.

## Next steps

* T-rustfmt team discussion
* T-rustfmt RFC
* Implementation of nightly flags within rustfmt
* https://github.com/rust-lang/rustfmt/issues/5721 related issue
* rustfmt doesn't know about features, only AST
* [..]

## Blockers