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.