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