r/wg21
P3844R4 - Reword [simd.math] for consteval conversions WG21Update
Posted by u/simd_follower · 4 hr. ago

Document: P3844R4
Author: Matthias Kretz
Date: 2026-02-13
Audience: LWG
Target: C++26
Prior revision: P3844R3 thread

R4 splits the [simd.math] respecification out from the consteval broadcast constructor work in R3. The title changed from "Restore simd::vec broadcast from int" to "Reword [simd.math] for consteval conversions" to reflect the narrower scope. Fixes incorrectly removed math-floating-point wording and an incorrect constraint in the hypot example from R3. LWG approved unanimously (9 F, 0 N, 0 A) on the 2026-02-13 telecon.

▲ 19 points (91% upvoted) · 6 comments
sorted by: best
u/overload_resolution_victim 14 points 3 hr. ago

Good - splitting the wording into two parts makes each reviewable in isolation. The consteval broadcast constructor is conceptually simple. The [simd.math] overload explosion (7 overloads per 3-arg function) is where the complexity lives and where the wording bugs were hiding.

u/revision_churn_tracker 11 points 3 hr. ago

R4 already? R3 was published the same day. I swear the simd papers iterate faster than my CI pipeline.

u/simd_lane_watcher 7 points 2 hr. ago

R3 had the consteval ctor + the math reword. R4 splits them and fixes two wording bugs from R3. It's the same content reorganized, not new design work.

u/lwg_telecon_lurker 9 points 2 hr. ago

9 in favor, 0 against, 0 neutral. Unanimous LWG approval. This is going into C++26. The math-floating-point fix they caught in R4 was exactly the kind of thing LWG review is designed to find.

u/vectorized_for_lunch 5 points 1 hr. ago

For anyone following the simd saga: the consteval broadcast constructor (R3's main contribution) is a separate concern from this. R4 is purely about making the math functions work correctly when one argument triggers the consteval path. The deduced-vec-t overload sets avoid immediate-escalation by doing conversions before the function call.