Date: Thu, 26 Feb 2026 12:49:50 -0500
So as long as I am making lots of corrections and updates to the Direction,
I am going to open it up to everyone for comments and feedbacks. I
have updated with Arthur's suggestions.
Thank you.
https://docs.google.com/document/d/1peO9efEK4Ey7jvvZrWt_7K46kHVz875IF8ILFWfvVaA/edit?tab=t.0
On Thu, Feb 26, 2026 at 12:29 PM Michael Wong <fraggamuffin_at_[hidden]>
wrote:
> Thanks for the note. I will update and use this chance to clean up the
> agenda.
>
> On Thu, Feb 26, 2026 at 12:22 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
>
>> On Thu, Feb 26, 2026 at 11:41 AM Michael Wong via SG14 <
>> sg14_at_[hidden]> wrote:
>>
>>> Hi John,
>>>
>>> The February minutes haven't been published yet — I'll get those out
>>> shortly.
>>>
>>> The networking constraints in Section 2 reflect discussions that go back
>>> quite a while in SG14 — this has been a recurring theme from our finance
>>> and embedded constituencies for years. That said, R0 stated the position
>>> too specifically and drew some justified criticism for naming specific
>>> proposals rather than articulating requirements. I have R1 ready, which
>>> rewrites Section 2 to frame SG14's architectural constraints (zero
>>> allocation on the hot path, transparent cost model, coroutine-optional,
>>> framework independence) without recommending for or against any specific
>>> proposal. R1 also corrects an error in Section 4.2 regarding the status of
>>> P1112 and P1847.
>>>
>>> Please feel free to circulate R1.
>>>
>>
>> P4029R1 favorably mentions P3707 "is_always_exhaustive". I think that's
>> misguided, especially given the recent/ongoing LEWG discussion (see
>> https://lists.isocpp.org/lib-ext/2026/02/31231.php ). That paper isn't
>> at all clear what problem it's trying to solve, and of the candidate
>> problems given in the paper it does *not* solve them. P3707 certainly
>> has nothing at all to do with "switch statements" — P4029R1 gives me the
>> impression that its author didn't read any more than the title of P3707.
>>
>> P4029R1 also mentions P0059 "ring_span" as if that paper is still active.
>> It is not. See
>> https://stackoverflow.com/questions/76856176/why-is-the-circular-buffer-not-standardized-in-c/
>> .
>>
>> The "agenda" emails you send out for the monthly meetings also have items
>> that haven't been updated in two years. E.g. my two-year-old announcement
>> that "LEWG will be seeing my P3055 "Relax wording to permit relocation
>> optimizations in the STL" in a telecon on February 20th"; e.g. "P2327
>> de-deprecating volatile received a "consensus" straw poll"; etc. etc.
>> Strongly recommend just deleting that old cruft. If there's no news
>> (known), just say "No news" (or say nothing). That's an easy improvement
>> you can make today.
>> A stretch goal could be to put the actual agenda for the upcoming meeting
>> in the email.
>>
>> –Arthur
>>
>
I am going to open it up to everyone for comments and feedbacks. I
have updated with Arthur's suggestions.
Thank you.
https://docs.google.com/document/d/1peO9efEK4Ey7jvvZrWt_7K46kHVz875IF8ILFWfvVaA/edit?tab=t.0
On Thu, Feb 26, 2026 at 12:29 PM Michael Wong <fraggamuffin_at_[hidden]>
wrote:
> Thanks for the note. I will update and use this chance to clean up the
> agenda.
>
> On Thu, Feb 26, 2026 at 12:22 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
>
>> On Thu, Feb 26, 2026 at 11:41 AM Michael Wong via SG14 <
>> sg14_at_[hidden]> wrote:
>>
>>> Hi John,
>>>
>>> The February minutes haven't been published yet — I'll get those out
>>> shortly.
>>>
>>> The networking constraints in Section 2 reflect discussions that go back
>>> quite a while in SG14 — this has been a recurring theme from our finance
>>> and embedded constituencies for years. That said, R0 stated the position
>>> too specifically and drew some justified criticism for naming specific
>>> proposals rather than articulating requirements. I have R1 ready, which
>>> rewrites Section 2 to frame SG14's architectural constraints (zero
>>> allocation on the hot path, transparent cost model, coroutine-optional,
>>> framework independence) without recommending for or against any specific
>>> proposal. R1 also corrects an error in Section 4.2 regarding the status of
>>> P1112 and P1847.
>>>
>>> Please feel free to circulate R1.
>>>
>>
>> P4029R1 favorably mentions P3707 "is_always_exhaustive". I think that's
>> misguided, especially given the recent/ongoing LEWG discussion (see
>> https://lists.isocpp.org/lib-ext/2026/02/31231.php ). That paper isn't
>> at all clear what problem it's trying to solve, and of the candidate
>> problems given in the paper it does *not* solve them. P3707 certainly
>> has nothing at all to do with "switch statements" — P4029R1 gives me the
>> impression that its author didn't read any more than the title of P3707.
>>
>> P4029R1 also mentions P0059 "ring_span" as if that paper is still active.
>> It is not. See
>> https://stackoverflow.com/questions/76856176/why-is-the-circular-buffer-not-standardized-in-c/
>> .
>>
>> The "agenda" emails you send out for the monthly meetings also have items
>> that haven't been updated in two years. E.g. my two-year-old announcement
>> that "LEWG will be seeing my P3055 "Relax wording to permit relocation
>> optimizations in the STL" in a telecon on February 20th"; e.g. "P2327
>> de-deprecating volatile received a "consensus" straw poll"; etc. etc.
>> Strongly recommend just deleting that old cruft. If there's no news
>> (known), just say "No news" (or say nothing). That's an easy improvement
>> you can make today.
>> A stretch goal could be to put the actual agenda for the upcoming meeting
>> in the email.
>>
>> –Arthur
>>
>
Received on 2026-02-26 17:50:06
