[2024-03 LWG Motion 9] Atomic minimum/maximum

[jensmaurer]

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p0493r5.pdf

[AlisdairM]

Requesting this be assigned to me

[AlisdairM]

Note 1 leaves me more confused than educated --- it is very easy to read that there are no pointers that have a weak ordering.

Suggest instead: Note 1: The < operator does not establish a strict weak ordering ([tab:cpp17.lessthancomparable][expr.rel]) unless comparing subobjects of the same complete object, where array elements are subobjects of their array.

[AlisdairM]

The feature macro __cpp_lib_atomic_min_max is requesting support in freestanding, is that correct or an oversight?

[frederick-vs-ja]

Suggest instead: Note 1: The < operator does not establish a strict weak ordering ([tab:cpp17.lessthancomparable][expr.rel]) unless comparing subobjects of the same complete object, where array elements are subobjects of their array.

This is still possibly misleading in the case where both complete objects are nested within the same byte array. But the core wording seems a bit unclear on the address of an object whose storage is provided-for...

[jwakely]

The feature macro __cpp_lib_atomic_min_max is requesting support in freestanding, is that correct or an oversight?

Everything else in <atomic> is freestanding, except for the atomic_signed_lock_free and atomic_unsigned_lock_free aliases.

The new non-member functions like atomic_fetch_max are marked freestanding. The members fetch_max and fetch_min are part of a fully freestanding class template (e.g. not marked partially freestanding).

So the feature test macro should match, and also be defined for freestanding.

[AlisdairM]

Sorry, should have pushed the PR before the weekend.

[AlisdairM]

Note that the initial pull request #6918 does not revise the comment from the paper. If there is consensus on a clearer wording, let me know and I can apply it. Alternatively, we can defer clarifying the comment to a separate editorial PR after all the Tokyo papers have landed.