P2835 R6 Expose std::atomic_ref's object address

wg21bot commented 1 year ago

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

ogiroux commented 1 year ago

Poll from SG1 in Varna:

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

wg21bot commented 1 year ago

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

gonzalobg commented 1 year ago

@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?

jensmaurer commented 1 year ago

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.

wg21bot commented 10 months ago

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

ednolan commented 10 months ago

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.

wg21bot commented 9 months ago

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

inbal2l commented 8 months ago

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).

SF	F	N	A	SA
5	8	3	0	0

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).

inbal2l commented 8 months ago

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

gonzalobg commented 7 months ago

@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)?

inbal2l commented 7 months ago

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)

wg21bot commented 6 months ago

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

inbal2l commented 4 months ago

P2835R4 was added to 2024 July LEWG electronic poll paper (P3314R0)

inbal2l commented 3 months ago

P2835R4 was forwarded in LEWG 2024 July electronic poll (outcomes: P3315R0). However, concerns came up regarding: the return value and optionality of the interface. P2835R5 was scheduled for Sep 3rd LEWG Telecon, to be finalized before forwarded to LWG for C++26.

inbal2l commented 2 months ago

2024-09-03 Library Evolution Telecon

P2835R5 Expose std::atomic_ref's object address

2024-09-03 Library Evolution Telecon Minutes

Champion: Gonzalo Brito Chair: Inbal Levi Minute Taker: Eddie Nolan

Summary

__POLL: Change the return type of the function accessing std::atomic_ref 's object address in P2835R5 to address_return_t / cv-qual void*__

SF	WF	N	WA	SA
1	6	2	3	2

Attendance: 20 Author Position: WF Outcome: No consensus for change

__POLL: Name the function accessing std::atomic_ref 's object address (T*, resulted from previous poll) in P2835R5 to:__ (you can vote multiple times, the name with the most votes will be picked)

Name	votes
get	1
address	12
data	0
ref	0
native_handle	1
handle	6

Attendance: 20 Outcome: The name “address” got the most support

__POLL: Rename the function accessing std::atomic_ref 's object address (returning T*, resulting from the previous poll) in P2835R5 into “address” and forward P2835R6 to LWG for C++26 (no need for EP, as a previous version of the paper was already forward).__

SF	WF	N	WA	SA
5	7	1	0	0

Attendance: 19 Author's Position: SF, SF Outcome: Consensus in favor

Next Steps

R2835R6 (with the requested name change) was forwarded to LWG for C++26 (no need for EP, as the paper was already voted).

wg21bot commented 2 months ago

P2835R5 Expose std::atomic_ref's object address (Gonzalo Brito Gadeschi, Mark Hoemmen, Carter H. Edwards, Bryce Adelstein Lelbach)

wg21bot commented 2 months ago

P2835R6 Expose std::atomic_ref's object address (Gonzalo Brito Gadeschi, Mark Hoemmen, Carter H. Edwards, Bryce Adelstein Lelbach)

JeffGarland commented 1 week ago

LWG reviewed and approved in Wroclaw

Poll: P2897r6 into C++26?

F	A	N
8	0	0

bstamour commented 1 week ago

LWG paper minutes: https://wiki.edg.com/bin/view/Wg21wroclaw2024/LWG20241118-P2835

cplusplus / papers