Point out that behavior might be switched on 2015 and 2018 too one day

[est31]

Reword documentation to make it clear that behaviour can be switched on older editions too, one day in the future. It doesn't have to be switched, but I think it's good to have it as an option and re-evaluate it a few months/years down the line when e.g. the crates that showed up in crater were broken by different changes in the language already.

cc #25725, #65819, #66145, #84147 , and #84133 (comment)

[rust-highfive]

r? @dtolnay

(rust-highfive has picked a reviewer for you, use r? to override)

[est31]

cc @nikomatsakis @LukasKalbertodt @cuviper

[cuviper]

That clarification seems good to me.

Somewhat aside, you changed "behavior" to "behaviour" -- I don't know if we have an official position for the project documentation, but the US spelling is far more common throughout the repo.

[est31]

the US spelling is far more common throughout the repo.

Hmmm you're right, indeed it is:

$ rg "behaviour" {library,compiler}/ | wc -l ; rg "behavior" {library,compiler}/ | wc -l
42
490

I've changed it to US spelling.

Also btw., if you check the summary comment of the August 2020 crater run, it lists the following major regression causing crates: colored, lazy_static, jpeg-decoder, ring. Interestingly, only ring has versions at all that use edition 2018, the other crates in that list all use edition 2015 for their latest versions, so I assume this includes the offending versions too. ring has switched to edition 2018 starting with 0.14.0, which means most of its breakage causing versions are on edition 2018.

[cuviper]

Also btw., if you check the summary comment of the August 2020 crater run, it lists the following major regression causing crates: colored, lazy_static, jpeg-decoder, ring. Interestingly, only ring has versions at all that use edition 2018, the other crates in that list all use edition 2015 for their latest versions, so I assume this includes the offending versions too. ring has switched to edition 2018 starting with 0.14.0, which means most of its breakage causing versions are on edition 2018.

Are you suggesting that we might want to migrate one edition without the other? If so, I think the only reason to force this at all would be to get rid of the attribute hack entirely, i.e. all or nothing.

[est31]

Are you suggesting that we might want to migrate one edition without the other?

I don't really know. I mainly shared this because I found it interesting. If there is a difference between 2015 and 2018 then it should only be in timing, for the reason you stated. Right now, I think it's better to perform this change as part of edition 2021 so that people can deliberately opt into the breakage. What one should do with 2015 and 2018 can be decided at a later point in time. I don't really want to turn this thread into a discussion about when to migrate edition 2015 and 2018.... maybe I shouldn't have shared that observation, my fault sorry... The point of this PR to explicitly leave the option open, nothing more nothing less.

[cuviper]

@bors r+ rollup

[bors]

📌 Commit 5bd3187 has been approved by cuviper

[nikomatsakis]

@bors r-

I'm not sure about this.

[nikomatsakis]

Let me explain:

I'm trying to decide what actionable thing we want people to based on this. I guess we're saying that we don't want them to use .foo() methods on older editions, because we might break them, and they should instead code against IntoIter::into_iter directly or something?

I think it would be good to spell out the advice.

[est31]

@nikomatsakis I've added a paragraph to the document. If I'm reading #84513 correctly it's also the plan to change the array_into_iter lint to make such suggestions as well.

[jackh726]

I think this failed in #84675

@bors r-

[cuviper]

Same issue as #84147 (comment), which I fixed for my test case in commit f6a90ca.

[cuviper]

@bors r=nikomatsakis

[bors]

📌 Commit a352336 has been approved by nikomatsakis

[nikomatsakis]

@bors rollup