From 99358cace71ae7d68feb41d4559cf6f0a9472a94 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Fri, 18 Oct 2024 10:59:43 +0200 Subject: [PATCH 1/2] clarify that (0.0 / 0.0).is_sign_positive() cannot yet be called in const fn --- posts/2024-10-17-Rust-1.82.0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/posts/2024-10-17-Rust-1.82.0.md b/posts/2024-10-17-Rust-1.82.0.md index 62d302af1..b48225faa 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 become const-stable with the next release) 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 From 621523a89784f1669cb0c57030da213e71566c7c Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Fri, 18 Oct 2024 16:07:27 +0000 Subject: [PATCH 2/2] Tighten up copy a bit --- posts/2024-10-17-Rust-1.82.0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/posts/2024-10-17-Rust-1.82.0.md b/posts/2024-10-17-Rust-1.82.0.md index b48225faa..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()` (which will become const-stable with the next release) 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