Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Style evolution #3338

Merged
merged 13 commits into from
Dec 5, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Discuss permanent vs temporary use of old style editions
  • Loading branch information
joshtriplett committed Nov 17, 2022
commit 80ee30d9234239c7cbaf22e65019d087c3e73d93
11 changes: 11 additions & 0 deletions text/3338-style-evolution.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,6 +87,17 @@ for handling forwards-compatibility and wonder how they differ. We feel that
since we're providing a mechanism similar to editions, we should make it clear
to users that it works like editions.

We could allow style edition to vary completely independently of Rust edition.
This would, for instance, allow projects to stay on old style editions
indefinitely. However, this would substantially increase the development and
testing burden for formatting tooling, and require more complex decisions about
how old style editions format constructs that didn't exist in the corresponding
Rust edition. In general, while the Rust edition mechanism allows projects to
stay on old Rust editions, and projects doing so can similarly stay on the
corresponding old style editions, the style edition mechanism does not exist to
facilitate staying on old styles *indefinitely* while still moving forward to
newer Rust editions.

We could leave out the separate configuration of style edition, and keep style
edition in lockstep with Rust edition. This would be easier to develop and
test, but would mean larger and noisier commits in projects transitioning from
Expand Down