(nb: throughout this document I’ll use extern_crate as a stand in for an extern crate name passed through--extern)
crate:: and ::crate:: paths will work everywhere(crate_in_paths)
mod.rs can die in a 🔥🔥🔥(this can be done in a backcompat way and is independent of the others so I'm going to ignore this for here)
pub(crate) can be replaced with crate(also backcompat, also ignored)
We will politely ask you to replace crate-public pub items with crate(pub(crate) items). This is an idiom lint, as discussed below. Also to be ignored.
Edition concepts
I’ve split lints/changes into two categories. This may or may not be exposed to the user.
Edition"breakage"
This is code that must be fixed if you wish for your code to compile on Rust 2018.
An example is the addition of a new keyword, idents shadowing new keywords must be replaced with r#foo on the new edition.
Factors involved:
Impact: Ideally, the impact of this(LOC-wise) should be minimized
Applied to keywords: Choose keywords that aren't used a ton
Hygiene: Breakage should be as hygienic as possible
Applied to keywords: We have a plan for this. There are other edition breakages which are minor enough that we do not intend to solve this problem.
Lints: Must have good lints built into the compiler. These should be as perfect as possible, emitting rustfixable suggestions everywhere.
Applied to keywords: WIP 🙃
Reversibility: Ideally, fixing edition breakages should not cause your code to fail to compile on Rust 2015. Edition breakages shouldn't be a"clean break", it should be possible to gradually migrate to the new edition.
Applied to keywords: Replacing future edition keywords with raw idents does not cause the compiler to look at your code any differently(in fact in the current implementation, raw idents and future-keywords are lexed to the exact same construct). This gets a bit iffy around macros, but that's a whole other discussion 😩
Edition"idiom"
These are new idioms we wish for you to use on the new edition. For example, we really want you to use dyn in Rust 2018. But it’s totally okay if you don’t.
Factors involved:
Impact: It is totally okay for the impact of idiom lints to be vast. We don’t require you to fix these, it’s just that your code will be better with these and work better with the model we wish to push in the new edition
Lints: Should have lints as well. These lints can be made available to rustfix in a second pass mods(after you’ve fixed the critical stuff). Some of these can also be just flipped on as normal lints a couple months into the edition(this was the previous plan for the dyn lint)
Hygeine: These are just lints. It’s fine if they’re not hygenic.
Reversibility: It is okay if these are not reversible. While dyn will also work in Rust 2015, we would be fine even if it didn’t.
Exposing the separation of breakage vs idiom lints to the user does introduce more complexity to the edition process, but it overall leads to a more relaxed workflow. Fix the breakage lints immediately, but it’s fine if you slowly fix the idiom lints. This could be exposed as a rustfix --edition --minimal vs rustfix --edition --all , for example. Alternatively, these lints can be made Warn on the new edition a couple months into the release.
Misc factors
Optics: We care about how the edition is perceived both within and without the community. Too much breakage can be bad for optics.
Pedagogy: The new edition may introduce new mental models. The more“pure” they are the better, mixing with mental models from the previous edition may lead to confusion amongst newcomers. At the same time, we should also consider the learning process for folks switching editions, as well as possible confusions amongst newcomers when presented with code from multiple editions.
Proposed module changes
Edition concepts
Edition "breakage"
Edition "idiom"
Misc factors
Possible breakages with path RFC