So just to confirm, the announcement has been made on the LEWG mailing
list and is much as I said, I just wasn't aware that there was any
ambiguity about the situation, nor that there was an announcement
coming, so I made one.
At any rate, if you have concerns please raise them on the LEWG thread.
Thanks,
Matt

On 8/11/2021 11:16 pm, Ville Voutilainen via SG14 wrote:
> On Mon, 8 Nov 2021 at 00:14, 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.
>
> The features that get higher priority than std::hive are well
> thought-out and discussed components of existing practice.
> If you want to convince me that there's something unfair going on, you
> need to start making more sense.
> The scheduling decisions seem to be going in a fashion compatible with
> the priority plan, and it could just as well
> be said to be unfair if we suddenly deviate from that plan after
> working according to it for all of the C++23 cycle.
> For the remaining scheduling and prioritizing of Bucket 3 items, I'm
> sure someone will be unhappy about every
> possible decision that could be made, and the whole idea of the train
> model we've operated with since
> the C++14 cycle is that if you didn't get on a particular train, board
> the next one.
>
> There's of course the possibility of changing our planning and
> execution approach. No proposals for doing that
> have materialized, so the only logical conclusion is that the
> complaints on various forums are not something
> we should take seriously. The onus is on the complainers to prove otherwise.
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>