Date: Sun, 7 Dec 2025 19:26:30 +0000
On Sun, 7 Dec 2025, 19:11 Marcin Jaczewski, <marcinjaczewski86_at_[hidden]>
wrote:
> niedz., 7 gru 2025 o 19:05 Jonathan Wakely via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
> >
> >
> >
> > On Sun, 7 Dec 2025, 15:04 Juan Lucas Rey, <juanlucasrey_at_[hidden]>
> wrote:
> >>
> >>
> >> Also something that is confusing to me from this process is that, if
> the standard specifies that the return values from generate_canonical are
> to be smaller than 1, then why is the standard concerned with
> implementation problems? why does LWG 2525 even exist? If the standard says
> it should return values in [0,1), and implementations don’t respect that,
> then that’s hardly a problem of the standard right?
> >>
> >> That seems to be an implementation problem, and is properly addressed
> at the implementation level by GCC #63176
> >
> >
> > The GCC solution is non-conforming. We are implementing p0952 as a
> better solution.
> >
> >> LLVM #18767
> >
> >
> > This isn't fixed yet, as far as I know.
> >
> >
> >> and MSVC STL #1074.
> >
> >
> > The MSVC solution was to implement p0952 which means it is not
> conforming to the old spec, because it sometimes discards random numbers.
> >
> > So it's not just an implementation problem if the spec is implementable,
> and so implementations can only be fixed by either breaking the rules of
> the standard or changing the standard.
> >
>
> If we need to break implementations by changing standard, could the
> standard at least require exact same results on every implementation?
>
No, not easily.
Like in multiplayer video games whole simulation is run indepedly on
> every machine and each one need to use diffrent compiler (like android
> phone have Clang, Linux use GCC and Windows use MSVC).
> If each implementation have freedom to use any algorithm as long it
> preserve probability then game will desync players with code from
> other compilers.
>
> Of course this will have drawbacks as sometimes some enforced
> algorithms will not be perfect and can't be updated if they have bugs.
> Maybe we should have some group of algorithms that guarantee the same
> results on all implementations?
>
https://wg21.link/p3375
wrote:
> niedz., 7 gru 2025 o 19:05 Jonathan Wakely via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
> >
> >
> >
> > On Sun, 7 Dec 2025, 15:04 Juan Lucas Rey, <juanlucasrey_at_[hidden]>
> wrote:
> >>
> >>
> >> Also something that is confusing to me from this process is that, if
> the standard specifies that the return values from generate_canonical are
> to be smaller than 1, then why is the standard concerned with
> implementation problems? why does LWG 2525 even exist? If the standard says
> it should return values in [0,1), and implementations don’t respect that,
> then that’s hardly a problem of the standard right?
> >>
> >> That seems to be an implementation problem, and is properly addressed
> at the implementation level by GCC #63176
> >
> >
> > The GCC solution is non-conforming. We are implementing p0952 as a
> better solution.
> >
> >> LLVM #18767
> >
> >
> > This isn't fixed yet, as far as I know.
> >
> >
> >> and MSVC STL #1074.
> >
> >
> > The MSVC solution was to implement p0952 which means it is not
> conforming to the old spec, because it sometimes discards random numbers.
> >
> > So it's not just an implementation problem if the spec is implementable,
> and so implementations can only be fixed by either breaking the rules of
> the standard or changing the standard.
> >
>
> If we need to break implementations by changing standard, could the
> standard at least require exact same results on every implementation?
>
No, not easily.
Like in multiplayer video games whole simulation is run indepedly on
> every machine and each one need to use diffrent compiler (like android
> phone have Clang, Linux use GCC and Windows use MSVC).
> If each implementation have freedom to use any algorithm as long it
> preserve probability then game will desync players with code from
> other compilers.
>
> Of course this will have drawbacks as sometimes some enforced
> algorithms will not be perfect and can't be updated if they have bugs.
> Maybe we should have some group of algorithms that guarantee the same
> results on all implementations?
>
https://wg21.link/p3375
Received on 2025-12-07 19:26:49
