On Fri, 14 May 2021 at 14:01, 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.

Some ruminations, first things first: the committee doesn't have a
budget or people on its payroll. It consists of volunteers who
have day jobs, in addition to which they work on standardization.

Then the next things: there's been all sorts of lofty suggestions to
have a catalog of curated C++ libraries that are installable
everywhere,
via whatever packaging system. I think that's missing a fundamental
goal, and shooting for the moon, thus failing to materialize
into anything. What I think we'd need _first_ is a catalog of C++
libraries so that I can *find* a library. I can then figure out
how to integrate it into my projects. Uniform packaging and quality
curation is a nice bonus, but unless I have that fundamental
first starting point, chances are that we're going to wait forever for
that magical curated uniformly packaged repository to appear.

But going back to the first things, this sort of endeavor would need
volunteers willing to do the work. I don't know where
to find such volunteers.

>
> 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