I am not a WG21 member. After 30 years of C++ commercial experiences and
usage, I might finally say something about this subject.

This is a productive initiative. Although the "big elephant in the corner"
is not the one you are trying to solve (it will certainly help), the core
issue is std:: is simply too big. And yes there are N+1 other descriptions
of this same issue.

And same as ABI "break" everybody is aware of the problem, but nobody has
convinced everybody (yet) there is a solution.

I personally think something will have to break (pun intended)

Kind regards



On Fri, 14 May 2021 at 12:59, Guy Cpp via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Not everything needs to go in the standard library. Discovery is a problem
> though. Why doesn't the committee host a library of useful things?
>
> Please offer your objections or support below.
>
> Cheers,
> G
>
> ---------- Forwarded message ---------
> From: Guy Cpp <guy.cpp.wg21_at_[hidden]>
> Date: Fri, 14 May 2021 at 08:31
> Subject: Re: [std-proposals] Distributed random number ordering
> To: <std-proposals_at_[hidden]>
>
>
> You know, we ALREADY HAVE https://github.com/cplusplus for committee
> matters. I've just looked through the 23 repositories there and as far as I
> can see only two have ANY C++ at all in them, lib-issues-software and LWG,
> and LWG seems to be a fork of lib-issues-software.
>
> What do I have to do to create a repository with some ACTUAL C++ in it,
> blessed by the committee, to resolve exactly this situation? Form a new
> study group which targets the committee library rather than the
> international standard? Could this seed the standard package manager that
> is just over the horizon? Would Compiler Explorer integration be useful?
>
> Maybe I should just write a proposal.
>
> Cheers,
> G
>
> On Wed, 12 May 2021 at 23:15, Arthur O'Dwyer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Wed, May 12, 2021 at 5:51 PM Jason McKesson via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On Wed, May 12, 2021 at 4:30 PM Lénárd Szolnoki via Std-Proposals
>>> <std-proposals_at_[hidden]> wrote:
>>> >
>>> > Hi,
>>> >
>>> > On the flip side mandating the algorithms also closes off further
>>> optimization opportunities from implementations. Also I wouldn't say that
>>> there are obvious algorithms to standardize even for discrete distributions.
>>> >
>>> > What comes to mind is adding an optional template parameter for
>>> distributions specifying a specific algorithm while having an
>>> implementation defined default.
>>>
>>> No, no "optional template parameters". I don't want to have to write
>>> `uniform_int_distribution<int, std::stable_distribution>`. I want to
>>> write `stable_uniform_int_distribution`, without having to specify the
>>> default type. And I imagine that implementation-wise, it's easier to
>>> just make a new type than to make a specialization, though this
>>> distinction is a bit trivial.
>>>
>>
>> Even better: Get the source code of `stable_uniform_int_distribution`
>> from a third-party GitHub repository, where if you ever do discover that
>> the behavior differs across platforms, you can just file a bug and it's
>> clearly on them to fix it. If you rely on the Standard Library for this
>> stuff, then you have nowhere (or rather, five or six places) to file bug
>> reports when it doesn't work.
>>
>> I see many reasons this should be on GitHub, and no reason this should be
>> in the Standard Library. (At least not for the computationally difficult
>> distributions with floating-point dependencies, like `normal_distribution`.
>> For `uniform_int_distribution` specifically, the Standard probably
>> *should* just mandate the algorithm, because it's relatively trivial.)
>>
>> –Arthur
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>