Okay, this all makes sense. Thank you!

> On Sep 4, 2025, at 10:31, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>
> On Thu, 4 Sept 2025 at 19:20, Nate Eldredge via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
>>
>> The current C++26 draft functionally removes memory_order_consume from the memory model. To this end, we have [depr.atomics.order] (https://eel.is/c++draft/depr.atomics.order) which defines `std::memory_order_consume` as having identical effect to `std::memory_order_acquire`, and defines `std::kill_dependency` as a no-op. This maintains backward compatibility with C++23, as acquire is strictly stronger than consume, and matches what most if not all implementations were doing in practice.
>>
>> But the remaining piece of consume ordering in C++23 and earlier was the [[carries_dependency]] attribute (see C++23 9.12.4 [dcl.attr.depend]). This does not appear to be mentioned anywhere in the C++26 draft, and I wonder if this is an oversight. Should [depr.atomics.order] additionally define [[carries_dependency]] as an attribute that has no effect?
>
> It isn't an oversight. See
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3475r2.pdf
> "Remove [dcl.attr.depend], which defines [[carries_dependency]] in its
> entirety. There is
> not a reason to deprecate it, since remaining occurrences in code will
> presumably be ignored
> anyway"
>
>> Otherwise, it would be theoretically permissible for a C++26 implementation to define [[carries_dependency]] for itself with some incompatible semantics, thus breaking otherwise valid C++23 code.
>
> Implementations don't do that, they use namespaced attributes for
> their own implementation-specific semantics. And in fact, they can't
> do that - once [[carries_dependency]] was removed, that name became
> reserved for future standardization as per
> [dcl.attr.grammar]/7.
>