Announcing Rust 1.82.0

[cuviper]

cc @rust-lang/release r? @Mark-Simulacrum

Rendered

[compiler-errors]

I believe https://github.com/rust-lang/rust/issues/129577 is missing from the release blog post. I think it's a quite important new feature and deserves being mentioned, if at least briefly.

That tracking issue currently lang-nominated, but I assume T-lang may not have the time to draft relnotes sections given a deadline.

I'm happy to help write something, though I'm very much not a good writer. Perhaps we could lift some verbiage from https://blog.rust-lang.org/2024/09/05/impl-trait-capture-rules.html#impl-traits-can-include-a-use-bound-to-specify-precisely-which-generic-types-and-lifetimes-they-use.

Also, process-wise, is there something we can do to ensure that things like this don't slip through the cracks?

[cuviper]

@compiler-errors precise capturing is listed in the release notes, and it was on our candidate list for the blog, but I dropped it because I wasn't sure what to say about it -- and we already have a lot more content than usual. It does have a place in the RPIT captures blog post, as far as it pertains to 2024.

For stable editions now, does it actually enable anything new though? AIUI you currently have to write all type parameters, and writing lifetime parameters like + use<'a> is the same as + 'a, isn't it? If there's more nuance, then that's what I need help writing. I do understand the need after the 2024 change, but that's not stable yet.

Process-wise, that's been lang-nominated since August 25th, so it was not a short deadline. Perhaps the team could further prioritize those that are also labeled for relnotes?

[compiler-errors]

Well, so + use<'a> is almost synonymous with + 'a, though + use<'a, 'b> is not the same as + 'a + 'b. I believe it's useful in 1.82 even in edition 2021 as a replacement for the Captures trick, and + use<> is a slightly more intentional way of writing + 'static in cases where there are no type parameters being captured. Not totally certain if that's significant enough, though.

[cuviper]

Hmm, OK, I think that earlier section on outlives has the extra nuance I was missing -- why the current syntax is insufficient.

[compiler-errors]

Process-wise, that's been lang-nominated since August 25th, so it was not a short deadline. Perhaps the team could further prioritize those that are also labeled for relnotes?

Yep. In general, I expect some growing pains from other teams learning how to deal with the new set of timely nominations :D

[cuviper]

@traviscross in theory, everything we mention in the blog is meant to be "fairly large user-facing," with the remainder left to the release notes alone. Items in the API list may be debatable on largeness, but we just dump that whole. Is there any part we included that perhaps you think is not blog worthy?

[traviscross]

The item about safe raw slices to statics could probably be dropped. It's essentially a bug fix.

All the other lang items there seem important to mention, in the sense that if they weren't there and someone later came back and said, "hey, how could you change that in Rust and not even bother to mention it in the release blog post?", that we'd feel they were right.

Lots of things came together for Rust 1.82. It's going to be an unusually substantial release.

Here's how I'd order the relative announcement importance of the lang items, starting at most important to highlight:

• use<..> syntax
• &raw syntax
• Unsafe extern
• Unsafe attributes
• min_exhaustive_patterns
• Floats in const
• asm_const
• Safe raw slices to statics

[cuviper]

I think since there's so much lang content, we should sandwich it to avoid overshadowing non-lang.

• cargo info
• Apple targets
• Lang stuff (in TC's order) ...
• Stabilized APIs