sure, but doesn't p0952r2 also breaks compatibility? even up to the
point of producing completely different numbers after a simulation is
discarded. With this proposal you can choose the "a" boundary
mentioned in the paper to make sure that only results that WOULD HAVE
returned 1.0 are changed.

On Thu, 4 Dec 2025 at 19:21, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>
>
> On Thu, 4 Dec 2025 at 19:06, Juan Lucas Rey via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> in the current proposal,
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0952r2.html
>
>
> That's not a current proposal, it was already approved by WG21 and added to the C++26 working draft in early 2024.
>
>>
>>
>>
>> it is mentioned "In particular, code that depends on a specific
>> sequence of results from repeated invocations, or on a particular
>> number of calls to the URBG argument, will be broken."
>>
>> This solution avoids breaking this.
>
>
> I don't see how you can avoid breaking compatibility by introducing a new function. I also don't see how you can avoid breaking compatibility for *any* change to the algorithm specified for std::generate_canonical in previous standards Unless you generate exactly the same sequence of numbers, then you break compatibility with the old version. And if you don't break compatibility with the old version, then you can produce 1.0.
>
> In particular, if you produce a completely different range of outputs, then you can't preserve compatibility with the original spec for std::generate_canonical.
>