Poll from SG1 in Varna:

Forward D2835R1 to LEWG for C++26
SF F N A SA
2 5 2 0 0
Unanimous consent

P2835R1 Expose std::atomic_ref's object address (Gonzalo Brito Gadeschi)

@ogiroux @inbal2l According to isocpp.org/papers, R1 is currently addressed to LEWG, but this issue appears to only have the SG1 tag. Would it be possible for LEWG to see it this week?

SG1 already voted to forward to LEWG, so it appears to be a clerical error that the labels haven't been adjusted accordingly. Fixing that now, @ogiroux, feel free to undo if I messed things up.

P2835R2 Expose std::atomic_ref's object address (Gonzalo Brito Gadeschi)

A motion to send this to electronic polling was started on the LEWG mailing list on Jan 22, 2024.
https://lists.isocpp.org/lib-ext/2024/01/26394.php

Summary:

• Reviewers discussed the naming of the new member function.
  • The status quo as of P2835R2 was data().
  • The author proposed address() as an alternative.
  • A reviewer noted that elsewhere in the standard library, data() refers to a contiguous range, and is paired with size(), making it less suitable as a name in this context.
  • A reviewer proposed get() by analogy with reference_wrapper. Another reviewer pointed out that, whereas users of reference_wrapper are free to access the underlying object through the wrapper or by using get(), users of atomic_ref are not allowed to access the underlying object while atomic_ref instances exist referencing it (atomics.ref.generic.general).
• Reviewers discussed the return type of the new member function.
  • A reviewer expressed support for the P2835 status quo of T const* since it describes the thing returned, and explored the idea of adding a non-const overload returning T*.
  • A reviewer expressed opposition to T const* on the basis that accessing the underlying value is always UB, so the returned pointer is only useful as an opaque value, and therefore shouldn't be dereferenceable. The reviewer expressed support for returning void const* or uintptr_t and proposed ideas for eliminating the 1-to-1 mapping from the address of the underlying value and the value returned by the member function.
  • A reviewer raised the point that uintptr_t is optional, so the method would become unavailable on implementations without uintptr_t if it was used as the return type.
  • A reviewer pointed out that [basic.compound] p3 requires specifying which thing a returned pointer would point to.
• Reviewers discussed the overall motivation of the proposal.
  • A reviewer objected to passing atomic_refs as parameters, claiming that the correct way to use atomic_ref is to wrap the uses, rather than the object, so the functions in the paper's example should have accepted a plain pointer type as a parameter and created atomic_ref objects at the point of use in the function, thereby making it possible to pass the plain pointer type to whatever mechanism would otherwise have required the new member function proposed by P2835.
  • Another reviewer responded that passing atomic_ref as a parameter is a legitimate, intended use case for the type, which does not mean that the user is wrapping the object instead of the uses, and provided example code for nested mdspan accessors which requires passing an atomic_ref parameter.

Due to the lack of consensus for the status quo as of P2835R2 and the desire for changes, more discussion is required and an updated paper will be scheduled for a LEWG meeting.

During the discussion, the author published a draft of an updated revision, D2835R3. The changes made are described in emails from January 22, January 25, and January 26.

P2835R3 Expose std::atomic_ref's object address (Gonzalo Brito Gadeschi)

2024-03-22 Library Evolution Tokyo Meeting

P2835R3: Expose std::atomic_ref's object address

2024-03-22 Library Evolution Tokyo Meening Minutes

Champion: Gonzalo Brito Gadeschi
Chair: Robert Leahy / Inbal Levi
Minute Taker: Guy Davidson

Summary

POLL:_ Forward “P2835R3: Expose std::atomic_ref 's object address” to LWG for C++26 (to be confirmed by an electronic poll).

Attendance: 21 + 8
Author's Position: SF
Outcome: Consensus in favor

Next Steps

Forward “P2835R3: Expose std::atomic_ref 's object address” to LWG for C++26 (to be confirmed by an electronic poll).

P2835R3 was added to 2024 April LEWG electronic poll paper (P3213R0)

@inbal2l Giuseppe discovered an issue with the paper post Tokyo that impacts its design. I'd like to release a new R4 that fixes it, and then send it back to LEWG. What's the process for this? Can it be removed from the electronic poll at the author's request (to make best use of everyone's time)?

As the EP paper hasn't been published yet, we'll pull this from the April EP, and re-add R4 after we see it in LEWG.
(next time please also send an explicit email for time-sensitive things, as the EP paper was about to get published, and I would have missed the notification on GitHub unless my co-chairs brought it to my attention)