Wording nits for const section

Co-authored-by: Ralf Jung <[email protected]>

Author: BoxyUwU

posts/2024-11-28-Rust-1.83.0.md

@@ -24,7 +24,7 @@ If you'd like to help us out by testing future releases, you might consider upda
 This release includes several large extensions to what code running in const contexts can do. This refers to all code that the compiler has to evaluate at compile-time: the initial value of `const` and `static` items, array lengths, enum discriminant values, const generic arguments, and functions callable from such contexts (`const fn`).
 
 **References to statics.**
-So far, `const` items and `const fn` were forbidden from referencing `static items`.
+So far, const contexts except for the initializer expression of a `static` item were forbidden from referencing `static` items.
 This limitation has now been lifted:
 ```rust
 static S: i32 = 25;
@@ -40,7 +40,9 @@ const C1: i32 = unsafe { S };
 const C2: &i32 = unsafe { &S };
 // error: encountered reference to mutable memory in `const`
 ```
-These limitations ensure that constants are still "constant": the value they evaluate to, and their meaning as a pattern (which can involve dereferencing references), will be the same throughout the entire program execution. However, a constant is permitted to evaluate to a raw pointer that points to a mutable or interior mutable static:
+These limitations ensure that constants are still "constant": the value they evaluate to, and their meaning as a pattern (which can involve dereferencing references), will be the same throughout the entire program execution.
+
+That said, a constant is permitted to evaluate to a raw pointer that points to a mutable or interior mutable static:
 ```rust
 static mut S: i32 = 64;
 const C: *mut i32 = &raw mut S;