Date: Fri, 14 May 2021 14:52:54 +0100
On Fri, 14 May 2021 at 12:16, Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:
> 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.
>
> I am mindful of the volunteer situation. I'm collecting constraints here,
and that's obviously a considerable one.
> 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.
>
> Perhaps we need to start with header-only libraries of class and function
templates? Would that limit the packaging problem until we have a solution?
> 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.
>
> Well, if this idea gains support, I can work on that. I just need to get
an idea of scope.
Thanks, Ville!
> >
> > 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
>
wrote:
> 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.
>
> I am mindful of the volunteer situation. I'm collecting constraints here,
and that's obviously a considerable one.
> 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.
>
> Perhaps we need to start with header-only libraries of class and function
templates? Would that limit the packaging problem until we have a solution?
> 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.
>
> Well, if this idea gains support, I can work on that. I just need to get
an idea of scope.
Thanks, Ville!
> >
> > 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
>
Received on 2021-05-14 08:53:10