C++ Logo

sg14

Advanced search

Re: [SG14] Support in LEWG regarding getting std::hive (nee colony) in C++23

From: Bryce Adelstein Lelbach aka wash <brycelelbach_at_[hidden]>
Date: Tue, 9 Nov 2021 13:41:06 -0500
No worries! We wanted to make sure we had the details right before the
announcement went out, I should have given you a heads up that one was
coming.

On Mon, Nov 8, 2021 at 4:33 PM Matt Bentley via SG14
<sg14_at_[hidden]> wrote:
>
> Apologies Bryce,
> I missed the note of ambiguity regards outcome in your email, and saw
> that the scheduled telecon had been removed. Didn't know there was an
> announcement coming, obviously.
> m
>
> On 8/11/2021 3:58 pm, Bryce Adelstein Lelbach aka wash via SG14 wrote:
> > I am surprised to see discussion of std::hive being taken off the C++23
> > schedule be announced, as I am the Library Evolution chair and have not
> > made any such announcement. I would encourage people to not jump to
> > conclusions regarding things that have not been announced.
> >
> > The committee has priorities that plenary voted on. See P0592.
> >
> > I'm not sure why people are bringing up S&R, which has nothing to do
> > with the scheduling of std::hive. At the last Library Evolution
> > supertelecon, I told the room we would have to schedule additional
> > meetings if they wanted to consider S&R for C++23. People voted in favor
> > of that. Those are additional meetings, and they do not impact our
> > regular telecon schedule.
> >
> > Library Evolution leadership will finalize our proposal for the rest of
> > the C++23 design cycle in the next few days and then publish it.
> >
> > --
> > Bryce Adelstein Lelbach aka wash (he/him/his)
> > US Programming Language Standards (PL22) Chair
> > ISO C++ Library Evolution Chair
> > CppCon and C++Now Program Chair
> > HPC Programming Models Architect @ NVIDIA
> > --
> >
> > On Sun, Nov 7, 2021, 19:19 JeanHeyd Meneide via SG14
> > <sg14_at_[hidden] <mailto:sg14_at_[hidden]>> wrote:
> >
> > On Sun, Nov 7, 2021 at 5:14 PM René Ferdinand Rivera Morell via SG14
> > <sg14_at_[hidden] <mailto:sg14_at_[hidden]>> wrote:
> > >
> > > On Sun, Nov 7, 2021 at 3:49 PM Matt Bentley via SG14
> > <sg14_at_[hidden] <mailto:sg14_at_[hidden]>> wrote:
> > >>
> > >> Just an update to all,
> > >> unfortunately the elders of LEWG have decided to postpone hive
> > telecon
> > >> till the C++26 period, for reasons of:
> > >> 1. There are many other things in the pipeline which have
> > already been
> > >> discussed and desperately need further discussion in order to
> > >> make/not-make it into C++23.
> > >> 2. They believe Hive would need a couple of telecons at least in
> > order
> > >> to properly discuss, and there isn't the time.
> > >>
> > >> I think these are fair reasons, though it seems to me to be a slight
> > >> mistep as the paper is pretty solid at this point and doesn't
> > require a
> > >> lot of adjustment I think.
> > >
> > >
> > > Thank you for the update. But I disagree on your estimation. I
> > think it is unfair. Unfair that a well thought out, and discussed,
> > component of existing practice is overridden by priorities of not as
> > grounded features.
> >
> > I agree. I'd use std::hive a million times more than I would have any
> > use of S&R in the next 4 years. Not to say it's not a worthwhile
> > pursuit, but making a scrambled-dash to put it in when waiting - since
> > we aren't going to be building on top of S&R until C++26 or later
> > anyways - is a decision that, on its face, seems unwise.
> >
> > It is certainly not unfair to categorize the decision as unfair (hah!)
> > when other proposals which have seen much more existing practice and
> > bake time get sidelined. I agree with just about anyone else that S&R
> > is a great direction and foundational and many other praises that have
> > been extensively laid out through dozens of hours of impassioned
> > discussion, not to mention foundational for supercomputing in general!
> > But, it should not dominate C++23 work in the slightest, and the
> > authors of it deserve time to continue to bake and shape it so that
> > it's in a great form that delivers on its promises, and we should not
> > be kicking them into overdrive to deliver. Fmt was the closest we had
> > to perfect and we still almost got locked into a bad ABI problem
> > providing tiny tweaks.
> >
> > I absolutely do not want to be in a position of "well, gosh, there's
> > this awesome thing that we could do with S&R, but we sort of made a
> > suboptimal decision / spec mistake, and now we can't go backwards".
> >
> > Sincerely,
> > JeanHeyd
> > _______________________________________________
> > SG14 mailing list
> > SG14_at_[hidden] <mailto:SG14_at_[hidden]>
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> > <https://lists.isocpp.org/mailman/listinfo.cgi/sg14>
> >
> >
> > _______________________________________________
> > SG14 mailing list
> > SG14_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> >
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14



-- 
Bryce Adelstein Lelbach aka wash (he/him/his)
US Programming Language Standards (PL22) Chair
ISO C++ Library Evolution Chair
CppCon and C++Now Program Chair
HPC Programming Models Architect @ NVIDIA
--

Received on 2021-11-09 12:41:34