update rust 1.82 draft

originals/announcements/2024-10-17-Rust-1.82.0.md

@@ -59,9 +59,9 @@ The Rust target `aarch64-apple-darwin` for macOS on 64-bit ARM (M1-family or lat
 
 ### Precise capturing `use<..>` syntax
 
-Rust now supports `use<..>` syntax within certain impl Trait bounds to control which generic lifetime parameters are captured.
+Rust now supports `use<..>` syntax within certain `impl Trait` bounds to control which generic lifetime parameters are captured.
 
-Return-position impl Trait (RPIT) types in Rust *capture* certain generic parameters.  Capturing a generic parameter allows that parameter to be used in the hidden type.  That in turn affects borrow checking.
+Return-position `impl Trait` (RPIT) types in Rust *capture* certain generic parameters.  Capturing a generic parameter allows that parameter to be used in the hidden type.  That in turn affects borrow checking.
 
 In Rust 2021 and earlier editions, lifetime parameters are not captured in opaque types on bare functions and on functions and methods of inherent impls unless those lifetime parameters are mentioned syntactically in the opaque type.  E.g., this is an error:
 
@@ -238,11 +238,11 @@ To avoid interfering with crates that wish to support several Rust versions, `ma
 
 ### Floating-point NaN semantics and `const`
 
-Operations on floating-point values (of type `f32` and `f64`) are famously subtle. One of the reasons for this is the existence of "NaN values": this is short for "not a number", and is used to represent e.g. the result of `0.0 / 0.0`. What makes NaN values subtle is that more than one possible NaN value exists: a NaN value has a sign that can be checked with `f.is_sign_positive()`, and it has a "payload" that can be extracted with `f.to_bits()` -- however, both are entirely ignored by `==` (which always returns `false` on a NaN). Despite very successful efforts to standardize the behavior of floating-point operations across hardware architectures, the details of when a NaN is positive or negative and what its exact payload is differ across architectures. To make matters even more complicated, Rust and its LLVM backend apply optimizations to floating-point operations when the exact numeric result is guaranteed not to change, but those optimizations can change which NaN value is produced. For instance, `f * 1.0` may be optimized to just `f`. However, if `f` is a NaN, this can change the exact bit pattern of the result!
+Operations on floating-point values (of type `f32` and `f64`) are famously subtle. One of the reasons for this is the existence of NaN ("not a number") values which are used to represent e.g. the result of `0.0 / 0.0`. What makes NaN values subtle is that more than one possible NaN value exists. A NaN value has a sign (that can be checked with `f.is_sign_positive()`) and a payload (that can be extracted with `f.to_bits()`). However, both the sign and payload of NaN values are entirely ignored by `==` (which always returns `false`). Despite very successful efforts to standardize the behavior of floating-point operations across hardware architectures, the details of when a NaN is positive or negative and what its exact payload is differ across architectures. To make matters even more complicated, Rust and its LLVM backend apply optimizations to floating-point operations when the exact numeric result is guaranteed not to change, but those optimizations can change which NaN value is produced. For instance, `f * 1.0` may be optimized to just `f`. However, if `f` is a NaN, this can change the exact bit pattern of the result!
 
 With this release, Rust standardizes on a set of rules for how NaN values behave. This set of rules is *not* fully deterministic, which means that the result of operations like `(0.0 / 0.0).is_sign_positive()` can differ depending on the hardware architecture, optimization levels, and the surrounding code. Code that aims to be fully portable should avoid using `to_bits` and should use `f.signum() == 1.0` instead of `f.is_sign_positive()`. However, the rules are carefully chosen to still allow advanced data representation techniques such as NaN boxing to be implemented in Rust code. For more details on what the exact rules are, check out our [documentation](https://doc.rust-lang.org/std/primitive.f32.html#nan-bit-patterns).
 
-With the semantics for NaN values settled, this release also permits the use of floating-point operations in `const fn`. Due to the reasons described above, operations like `(0.0 / 0.0).is_sign_positive()` can produce a different result when executed at compile-time vs at run-time; this is not a bug and code must not rely on a `const fn` always producing the exact same result.
+With the semantics for NaN values settled, this release also permits the use of floating-point operations in `const fn`. Due to the reasons described above, operations like `(0.0 / 0.0).is_sign_positive()` can produce a different result when executed at compile-time vs at run-time. This is not a bug, and code must not rely on a `const fn` always producing the exact same result.
 
 ### Constants as assembly immediates