Fwd: LWG 2524 (was Re: std::generate_canonical)

[Nathan Myers]

I posted this to a smaller group earlier...

-------- Forwarded Message --------
Subject: LWG 2524 (was Re: std::generate_canonical)
Date: Mon, 11 Aug 2025 11:21:38 -0400

Reviewing LWG 2424 and minutes from 2024-11 when it seems it was last
discussed [...]. Is it a Defect, so should be applied even when building
under "-std=c++11" or something else, or only under "-std=c++26"
and later targets? The Kona plenary vote seems to plop P0952R9 only
into the C++26 WP.

Getting all the up-front calculations done at compile time was
tricky, and I am doubtful the language pre-2023 is up to the job,
particularly use of std::floor which becomes constexpr only
in C++23 [and still is not constexpr in Clang. We could say
   [](T f) constexpr { return (T)(unsigned long long)(f - 0.5); }
for that case, but do we want to?]

The final question below remains: should use be restricted
to float, double, and long double as spelled out clearly in the WP,
or permitted for other C++23 P1467R9 types like bfloat32_t (distinct
from float despite being bitwise-identical)? And if the latter, is
it a Defect that the WP forbids those? std::is_floating_point
in C++23 admits them all.

On 8/10/25 00:41, Nathan Myers wrote:
> [...]
> Do you recommend any shortcuts? In particular, might the
> candidate final value, (ret = std::floor(sum/x)/rd), better be
> optimistically computed inside the do-while loop and simply
> compared to 1.0, eliminating the need for an intermediate
> value x*r^d to compare S against?
> [...]
> Finally: the WP says it may only be applied to float, double,
> and long double. Do you think that should be enforced, or
> should it only enforce std::is_floating_point, which admits
> a variety of other formats?
[code elided]