Edition 2021 blog post

[m-ou-se]

cc @rust-lang/project-edition-2021

Rendered

Closes rust-lang/rust#84593

[ChrisDenton]

In the panic section, should panic_any be briefly mentioned as an alternative for rarer use cases?

[m-ou-se]

In the panic section, should panic_any be briefly mentioned as an alternative for rarer use cases?

I don't think so. This is not the edition guide; just an overview. I only very quickly mention the existence of non-string panics, which are rather uncommon.

Edit: Added a small note now.

[therealprof]

Hm, I'm seeing a contradiction in the text:

for e in [1, 2, 3] {} // Error :(

and later it says:

It does not affect any other syntax such as for e in [1, 2, 3] or iter.zip([1, 2, 3]). Those will start to work in all editions.

Did you mean to say for e in &[1, 2, 3]?

Also I find it strange that for &e in &[1, 2, 3] {} // Ok :) is mentioned since I don't see that &esyntax too often and it might throw off some readers...

[m-ou-se]

@therealprof That snippet describes the current situation, before Rust 1.53.

Until Rust 1.53, [..]

Starting in 1.53, we will have that trait implementation and for e in [1, 2, 3] {} will start to work in all editions.

[..] Those will start to work in all editions.

[therealprof]

@m-ou-se Thanks for pointing out how bad of a reader I am. 😅 After a few more passes I can parse that correctly, so 👍 from me. I'd still change

for &e in &[1, 2, 3] {}

to

for e in &[1, 2, 3] {}

so the important difference stands out a bit clearer.

[m-ou-se]

I purposely put that & there, to make it clear that iterating over &[1, 2, 3] results in &i32, not i32. Otherwise the difference might just seem like you can now write in [..] instead of in &[..] with no semantic difference.

[therealprof]

I purposely put that & there, to make it clear that iterating over &[1, 2, 3] results in &i32, not i32. Otherwise the difference might just seem like you can now write in [..] instead of in &[..] with no semantic difference.

Fair enough, what about ref e then to make it more expressive?

[m-ou-se]

Fair enough, what about ref e then to make it more expressive?

That does the opposite. That will add a reference, giving you &&i32:

    for ref e in &[1, 2, 3] {
        let _: i32 = **e;
    }

[therealprof]

I guess I really need to shut up and hide in a dark place now to read up on the syntax quirks and automatic derefencing. 😅 Thanks for the education.

[Mark-Simulacrum]

I think pushing this out to May 10th or 11th would be good. By then I hope that we can have the primary edition RFC merged and the changes still in-flight (e.g., T-libs approval of prelude, token reservation RFC merged) also finished up.

[steffahn]

When reading rust-lang/rust#84147, I found it noteworthy that in particular IntoIterator::into_iter([1, 2, 3]) will work in Rust 2018/2015, too. Maybe that could be mentioned as another example around

syntax such as for e in [1, 2, 3] or iter.zip([1, 2, 3]). Those will start to work in all editions.

[m-ou-se]

@bstrie, @steffahn, @digama0: Thanks for the feedback.

[m-ou-se]

I think pushing this out to May 10th or 11th would be good. By then I hope that we can have the primary edition RFC merged and the changes still in-flight (e.g., T-libs approval of prelude, token reservation RFC merged) also finished up.

Sounds good. @rust-lang/core can y'all review it this week so we can publish it next Monday?

[m-ou-se]

@Mark-Simulacrum Can we get this merged and published today? :)

[Mark-Simulacrum]

I think let's go for tomorrow: it seems likely this wants good coverage, but today we're merging #836 and that'll likely distract from this.

[m-ou-se]

tomorrow

$ date +%F
2021-05-11

:D