diff --git a/posts/2024-10-17-Rust-1.82.0.md b/posts/2024-10-17-Rust-1.82.0.md
index 62d302af1..b79b71e59 100644
--- a/posts/2024-10-17-Rust-1.82.0.md
+++ b/posts/2024-10-17-Rust-1.82.0.md
@@ -242,7 +242,7 @@ Operations on floating-point values (of type `f32` and `f64`) are famously subtl
 
 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()` (which will be const-stable in Rust 1.83) 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