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]>
wrote:
> On Sun, Nov 7, 2021 at 5:14 PM René Ferdinand Rivera Morell via SG14
> <sg14_at_[hidden]> wrote:
> >
> > On Sun, Nov 7, 2021 at 3:49 PM Matt Bentley via SG14 <
> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>