Date: Fri, 16 Jan 2026 06:07:46 -0500
> 3. P2616 seems to do something similar, but it wasn't adopted into C++26. You might want to investigate why that is.
This part from P2616r4 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2616r4.html> seems to directly address some of these issues and may provide some insight to the overall committee sentiment. I'd suggest contacting Lewis for the scoop on the previous discussions about this issue.
> This proposal does not attempt to change the definition of the namespace-scope functions std::atomic_notify_one/all().
>
> These functions are invoked with a pointer to the atomic object rather than being member functions. So unlike a call to the notify member-functions, which has undefined behaviour if the object's lifetime has ended, the behaviour of passing a pointer to an object whose lifetime has ended is implementation-defined.
>
> So while some implementations might define passing a pointer to an object whose lifetime has ended as valid, other implementations might choose to trap on such uses of a pointer, making writing portably correct code using this API difficult/impossible.
>
> Whether or not this can be made portably safe depends on the resolution to the "pointer zap" issue, which is the subject of papers P1726 and P2188, and so I do not attempt to address the issue in this paper.
> On Jan 15, 2026, at 12:25 AM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 1. A defect report is not a proposal. Proposals may be used to resolve a reported and accepted defect, but you don't write a proposal for both the defect and its proposed resolution. Before you put a proposal together to resolve a defect, that defect has to actually be *accepted*.
>
> 2. This is not a defect in the standard. If atomic were intended to be a foundational technology for the implementation of all thread synchronization primitives, then it might be considered a defect. But I've yet to see any citation from proposals that suggests that this was ever the case. You *personally* may think of them that way, and thus it's wrong for them to fail to achieve that. But I don't see where any of the atomic_notify* stuff was ever intended to be something that could be used to build up all other synchronization primitives.
>
> 3. P2616 seems to do something similar, but it wasn't adopted into C++26. You might want to investigate why that is.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
This part from P2616r4 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2616r4.html> seems to directly address some of these issues and may provide some insight to the overall committee sentiment. I'd suggest contacting Lewis for the scoop on the previous discussions about this issue.
> This proposal does not attempt to change the definition of the namespace-scope functions std::atomic_notify_one/all().
>
> These functions are invoked with a pointer to the atomic object rather than being member functions. So unlike a call to the notify member-functions, which has undefined behaviour if the object's lifetime has ended, the behaviour of passing a pointer to an object whose lifetime has ended is implementation-defined.
>
> So while some implementations might define passing a pointer to an object whose lifetime has ended as valid, other implementations might choose to trap on such uses of a pointer, making writing portably correct code using this API difficult/impossible.
>
> Whether or not this can be made portably safe depends on the resolution to the "pointer zap" issue, which is the subject of papers P1726 and P2188, and so I do not attempt to address the issue in this paper.
> On Jan 15, 2026, at 12:25 AM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 1. A defect report is not a proposal. Proposals may be used to resolve a reported and accepted defect, but you don't write a proposal for both the defect and its proposed resolution. Before you put a proposal together to resolve a defect, that defect has to actually be *accepted*.
>
> 2. This is not a defect in the standard. If atomic were intended to be a foundational technology for the implementation of all thread synchronization primitives, then it might be considered a defect. But I've yet to see any citation from proposals that suggests that this was ever the case. You *personally* may think of them that way, and thus it's wrong for them to fail to achieve that. But I don't see where any of the atomic_notify* stuff was ever intended to be something that could be used to build up all other synchronization primitives.
>
> 3. P2616 seems to do something similar, but it wasn't adopted into C++26. You might want to investigate why that is.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2026-01-16 11:07:59