Merge pull request #2683 from integer32llc/epoch-to-edition

META: Replace "epoch" with "edition"

Author: Centril

text/2052-epochs.md

@@ -218,10 +218,10 @@ Although the mechanism for opt-in for the long-term solution is unspecified, the
 actual usage of tool attributes seems pretty clear. Therefore we can be reasonably
 confident that this proposal is forward-compatible in its syntax, etc.
 
-For the white-listed tools, will their names be implicitly imported in the long-
-term solution? One could imagine either leaving them implicit (similar to the
-libraries prelude) or using warning cycles or an epoch to move them to explicit
-opt-in.
+For the white-listed tools, will their names be implicitly imported in the
+long-term solution? One could imagine either leaving them implicit (similar to
+the libraries prelude) or using warning cycles or an edition to move them to
+explicit opt-in.
 
 
 # Drawbacks

text/2103-tool-attributes.md

@@ -6,14 +6,14 @@
 # Summary
 [summary]: #summary
 
-Introduce a new `dyn Trait` syntax for trait objects using a contextual `dyn` keyword, and deprecate "bare trait" syntax for trait objects. In a future epoch, `dyn` will become a proper keyword and a lint against bare trait syntax will become deny-by-default.
+Introduce a new `dyn Trait` syntax for trait objects using a contextual `dyn` keyword, and deprecate "bare trait" syntax for trait objects. In a future edition, `dyn` will become a proper keyword and a lint against bare trait syntax will become deny-by-default.
 
 # Motivation
 [motivation]: #motivation
 
 ### In a nutshell
 
-The current syntax is often ambiguous and confusing, even to veterans, and favors a feature that is not more frequently used than its alternatives, is sometimes slower, and often cannot be used at all when its alternatives can. By itself, that's not enough to make a breaking change to syntax that's already been stabilized. Now that we have epochs, it won't have to be a breaking change, but it will still cause significant churn. However, impl Trait is going to require a significant shift in idioms and teaching materials all on its own, and "dyn Trait vs impl Trait" is much nicer for teaching and ergonomics than "bare trait vs impl Trait", so this author believes it is worthwhile to change trait object syntax too.
+The current syntax is often ambiguous and confusing, even to veterans, and favors a feature that is not more frequently used than its alternatives, is sometimes slower, and often cannot be used at all when its alternatives can. By itself, that's not enough to make a breaking change to syntax that's already been stabilized. Now that we have editions, it won't have to be a breaking change, but it will still cause significant churn. However, impl Trait is going to require a significant shift in idioms and teaching materials all on its own, and "dyn Trait vs impl Trait" is much nicer for teaching and ergonomics than "bare trait vs impl Trait", so this author believes it is worthwhile to change trait object syntax too.
 
 Motivation is the key issue for this RFC, so let's expand on some of those claims:
 
@@ -74,15 +74,15 @@ The functionality of `dyn Trait` is identical to today's trait object syntax.
 
 ### Migration
 
-On the current epoch:
+On the current edition:
 - The `dyn` keyword will be added, and will be a contextual keyword
 - A lint against bare trait syntax will be added
 
-In the next epoch:
+In the next edition:
 - `dyn` becomes a real keyword, uses of it as an identifier become hard errors
 - The bare trait syntax lint is raised to deny-by-default
 
-This follows the policy laid out in the epochs RFC, where a hard error is "only available when the deprecation is expected to hit a relatively small percentage of code." Adding the `dyn` keyword is unlikely to affect much code, but removing bare trait syntax will clearly affect a lot of code, so only the latter change is implemented as a deny-by-default lint.
+This follows the policy laid out in the editions RFC, where a hard error is "only available when the deprecation is expected to hit a relatively small percentage of code." Adding the `dyn` keyword is unlikely to affect much code, but removing bare trait syntax will clearly affect a lot of code, so only the latter change is implemented as a deny-by-default lint.
 
 # Drawbacks
 [drawbacks]: #drawbacks
@@ -104,7 +104,7 @@ This author believes that `dyn` is a better choice because the notion of "dynami
 
 We could also use a more radical syntax for trait objects. `Object<Trait>` was suggested on the original RFC thread but didn't gain much traction, presumably because it adds more "noise" than a keyword and is arguably misleading.
 
-Finally, we could repurpose bare trait syntax for something other than trait objects. It's been frequently suggested in the past that impl Trait would be a far better candidate for bare trait syntax than trait objects. Even this RFC's motivation section indirectly argues for this, e.g. impl Trait does work with all traits and does not carry a runtime cost, unlike trait objects. However, this RFC does not propose repurposing bare trait syntax yet, only deprecating and removing it. This author believes dyn Trait is worth adding even if we never repurpose bare trait, and repurposing it has some significant downsides that dyn Trait does not (such as creating the possibility of code that compiles in two different epochs with radically different semantics). This author believes the repurposing debate should come later, probably after impl Trait and dyn Trait have been stabilized.
+Finally, we could repurpose bare trait syntax for something other than trait objects. It's been frequently suggested in the past that impl Trait would be a far better candidate for bare trait syntax than trait objects. Even this RFC's motivation section indirectly argues for this, e.g. impl Trait does work with all traits and does not carry a runtime cost, unlike trait objects. However, this RFC does not propose repurposing bare trait syntax yet, only deprecating and removing it. This author believes dyn Trait is worth adding even if we never repurpose bare trait, and repurposing it has some significant downsides that dyn Trait does not (such as creating the possibility of code that compiles in two different editions with radically different semantics). This author believes the repurposing debate should come later, probably after impl Trait and dyn Trait have been stabilized.
 
 # Unresolved questions
 [unresolved]: #unresolved-questions

text/2113-dyn-trait-syntax.md

@@ -277,7 +277,7 @@ impl<T> VecIter<'_, T> { ... }
 # Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation
 
-**Note: these changes are designed to *not* require a new epoch**. They do
+**Note: these changes are designed to *not* require a new edition**. They do
 expand our naming style lint, however.
 
 ## Lifetimes in `impl` headers

text/2115-argument-lifetimes.md

@@ -13,11 +13,11 @@ This RFC seeks to clarify and streamline Rust's story around paths and visibilit
 - The `crate` keyword also acts as a visibility modifier, equivalent to today's `pub(crate)`. Consequently, uses of bare `pub` on items that are not actually publicly exported are linted, suggesting `crate` visibility instead.
 - A `foo.rs` and `foo/` subdirectory may coexist; `mod.rs` is no longer needed when placing submodules in a subdirectory.
 
-**These changes do not require a new epoch**. The new features are purely additive. They can ship with **allow-by-default** lints, which can gradually be moved to warn-by-default and deny-by-default over time, as better tooling is developed and more code has actively made the switch.
+**These changes do not require a new edition**. The new features are purely additive. They can ship with **allow-by-default** lints, which can gradually be moved to warn-by-default and deny-by-default over time, as better tooling is developed and more code has actively made the switch.
 
 *This RFC incorporates some text written by @withoutboats and @cramertj, who have both been involved in the long-running discussions on this topic.*
 
-[new epoch]: https://github.com/rust-lang/rfcs/pull/2052
+[new edition]: https://github.com/rust-lang/rfcs/pull/2052
 
 # Motivation
 [motivation]: #motivation
@@ -447,7 +447,7 @@ The actual changes in this RFC are fairly small tweaks to the current module
 system; most of the complexity comes from the migration plans.
 
 The proposed migration plan is minimally disruptive; **it does not require an
-epoch**.
+edition**.
 
 ## Basic changes
 
@@ -507,11 +507,11 @@ and Cargo/the ambient build system is needed.
 This approach is designed for backwards compatibility, but it means that you
 cannot have a top-level module and an external crate with the same
 name. Allowing that would require all fully-qualified paths into the current
-crate to start with `crate`, which can only be done on a future epoch. We can
+crate to start with `crate`, which can only be done on a future edition. We can
 and should consider making such a change eventually, but it is not required for
 this RFC.
 
-[epoch]: https://github.com/rust-lang/rfcs/pull/2052
+[edition]: https://github.com/rust-lang/rfcs/pull/2052
 [macros 2.0]: https://github.com/rust-lang/rfcs/blob/master/text/1561-macro-naming.md#importing-macros
 [previous RFC]: https://github.com/rust-lang/rfcs/pull/2088
 
@@ -574,14 +574,14 @@ motivation. The crucial insight of the design is that, by making absolute paths
 unambiguous about which crate they draw from, we can solve a number of
 confusions and papercuts with the module system.
 
-## Epoch-based migration story
+## Edition-based migration story
 
-We can avoid the need for fallback in resolution by leveraging epochs instead.
-On the current epoch, we would make `crate::` paths available and start warning
-about *not* using them for crate-internal paths, but we would not issue warnings
-about `extern crate`. In the next epoch, we would change absolute path
-interpretations, such that warning-free code on the previous epoch would
-continue to compile and have the same meaning.
+We can avoid the need for fallback in resolution by leveraging editions
+instead. On the current edition, we would make `crate::` paths available and
+start warning about *not* using them for crate-internal paths, but we would not
+issue warnings about `extern crate`. In the next edition, we would change
+absolute path interpretations, such that warning-free code on the previous
+edition would continue to compile and have the same meaning.
 
 ## Bike-sheddy choices
 
@@ -652,6 +652,6 @@ ideas off into a separate *experimental* RFC:
 # Unresolved questions
 [unresolved]: #unresolved-questions
 
-- How should we approach migration? Via a fallback, as proposed, or via epochs?
-  It is probably best to make this determination with more experience,
+- How should we approach migration? Via a fallback, as proposed, or via
+  editions? It is probably best to make this determination with more experience,
   e.g. after we have a `rustfix` tool in hand.

text/2126-path-clarity.md

@@ -7,16 +7,17 @@
 [summary]: #summary
 
 Add a raw identifier format `r#ident`, so crates written in future language
-epochs/versions can still use an older API that overlaps with new keywords.
+editions/versions can still use an older API that overlaps with new keywords.
 
 # Motivation
 [motivation]: #motivation
 
-One of the primary examples of breaking changes in the epoch RFC is to add new
-keywords, and specifically `catch` is the first candidate. However, since
-that's seeking crate compatibility across epochs, this would leave a crate in a
-newer epoch unable to use `catch` identifiers in the API of a crate in an older
-epoch.  [@matklad found] 28 crates using `catch` identifiers, some public.
+One of the primary examples of breaking changes in the edition RFC is to add
+new keywords, and specifically `catch` is the first candidate. However, since
+that's seeking crate compatibility across editions, this would leave a crate in
+a newer edition unable to use `catch` identifiers in the API of a crate in an
+older edition. [@matklad found] 28 crates using `catch` identifiers, some
+public.
 
 A raw syntax that's *always* an identifier would allow these to remain
 compatible, so one can write `r#catch` where `catch`-as-identifier is needed.
@@ -57,14 +58,14 @@ they are mentioned, making them cumbersome to both the developer and users.
 Usually an alternate is preferable: `crate` -> `krate`, `const` -> `constant`,
 etc.
 
-However, new Rust epochs may add to the list of reserved keywords, making a
-formerly legal identifier now interpreted otherwise.  Since compatibility is
-maintained between crates of different epochs, this could mean that code written
-in a new epoch might not be able to name an identifier in the API of another
-crate.  Using a raw identifier, it can still be named and used.
+However, new Rust editions may add to the list of reserved keywords, making a
+formerly legal identifier now interpreted otherwise. Since compatibility is
+maintained between crates of different editions, this could mean that code
+written in a new edition might not be able to name an identifier in the API of
+another crate. Using a raw identifier, it can still be named and used.
 
 ```rust
-//! baseball.rs in epoch 2015
+//! baseball.rs in edition 2015
 pub struct Ball;
 pub struct Player;
 impl Player {
@@ -74,7 +75,7 @@ impl Player {
 ```
 
 ```rust
-//! main.rs in epoch 2018 -- `catch` is now a keyword!
+//! main.rs in edition 2018 -- `catch` is now a keyword!
 use baseball::*;
 fn main() {
     let mut player = Player;
@@ -107,9 +108,10 @@ let bar = r#foo * 2;
 [alternatives]: #alternatives
 
 If we don't have any way to refer to identifiers that were legal in prior
-epochs, but later became keywords, then this may hurt interoperability between
-crates of different epochs.  The `r#ident` syntax enables interoperability, and
-will hopefully invoke some intuition of being raw, similar to raw strings.
+editions, but later became keywords, then this may hurt interoperability
+between crates of different editions. The `r#ident` syntax enables
+interoperability, and will hopefully invoke some intuition of being raw,
+similar to raw strings.
 
 The `br#ident` syntax is also possible, but I see no advantage over `r#ident`.
 Identifiers don't need the same kind of distinction as `str` and `[u8]`.
@@ -153,12 +155,12 @@ Java also allows Unicode escapes, but they don't avoid keywords.
 For some new keywords, there may be contextual mitigations. In the case of
 `catch`, it couldn't be a fully contextual keyword because `catch { ... }` could
 be a struct literal. That context might be worked around with a path, like
-`old_epoch::catch { ... }` to use an identifier instead. Contexts that don't
+`old_edition::catch { ... }` to use an identifier instead. Contexts that don't
 make sense for a `catch` expression can just be identifiers, like `foo.catch()`.
 However, this might not be possible for all future keywords.
 
 There might also be a need for raw keywords in the other direction, e.g. so the
-older epoch can still use the new `catch` functionality somehow. I think this
+older edition can still use the new `catch` functionality somehow. I think this
 particular case is already served well enough by `do catch { ... }`, if we
 choose to stabilize it that way.  Perhaps `br#keyword` could be used for this,
 but that may not be a good intuitive relationship.
@@ -175,4 +177,4 @@ but that may not be a good intuitive relationship.
 
 - Do macros need any special care with such identifier tokens?
 - Should diagnostics use the `r#` syntax when printing identifiers that overlap keywords?
-- Does rustdoc need to use the `r#` syntax? e.g. to document `pub use old_epoch::*`
+- Does rustdoc need to use the `r#` syntax? e.g. to document `pub use old_edition::*`