1. Introduction
In 2026-09, the C++ Library Evolution group conducted an electronic poll [P4335R0]. This paper provides the results of this poll and summarizes the responses.
In total, 14 people participated in the polls. Thank you to everyone who participated, and to the papers' authors for all their hard work!
2. Poll Outcomes
-
SF: Strongly Favor.
-
WF: Weakly Favor.
-
N: Neutral.
-
WA: Weakly Against.
-
SA: Strongly Against.
| Poll | SF | WF | N | WA | SA | Outcome |
|---|---|---|---|---|---|---|
| Poll 1: Send "P0870R8: A proposal for a type trait to detect narrowing conversions" (with added reflection type trait) back to LWG for C++29. | 10 | 3 | 0 | 0 | 0 | Consensus in favor |
| Poll 2: Modify "P2249R6: Mixed comparisons for smart pointers" with the action items described below, and forward to LWG for C++29. | 8 | 4 | 0 | 0 | 0 | Consensus in favor |
| Poll 3: Apply naming changes ("notify_is.." into "is_notify" (etc.), and the FTM) and forward the updated "P3255R3: Expose whether atomic notifying operations are lock-free" to LWG for C++29 and as a DR up to C++20 (section 10 wording for DR, section 11 wording for C++29). | 6 | 5 | 0 | 1 | 0 | Consensus in favor |
| Poll 4: Apply changes (apply section 8 wording option A, the rename of the member functions from "high_bits" / "low_bits" into "high" and "low", and remove the "3 recommended practice") and re-send the updated "P3642R7: Carry-less product: std::clmul" to LWG for C++29. | 6 | 5 | 0 | 1 | 0 | Consensus in favor |
The polls had consensus in favor, and the paper will be forwarded to LWG for C++29.
3. Selected Poll Comments
For some of the comments, small parts were removed to anonymize.
3.1. Poll 1: Send "P0870R8: A proposal for a type trait to detect narrowing conversions" (with added reflection type trait) back to LWG for C++29.
This is essential to improving casting and where casting might be used in templates.
— Strongly Favor
This is incredibly useful. I’ve often wanted this facility. It’s error-prone to write by hand.
— Strongly Favor
The functionality provided by this is useful.
— Weakly Favor
This may change it meaning over time, but otherwise usefull.
— Weakly Favor
3.2. Poll 2: Modify "P2249R6: Mixed comparisons for smart pointers" with the action items described below, and forward to LWG for C++29.
Action items:
-
6.2.2 typo ‘<’ should be ‘>’ at end of compare_three_way_result_t line. Same line 2 below.
-
Ensure that the wording reflects the requirements under [hidden.friends] as the intent is for these comparisons to be hidden friends.
-
Ensure shared_ptr comparisons are constexpr (LWG/author should rebase on P3037).
This is essential to making smart pointers easier to use.
— Strongly Favor
Very reasonable addition, but we need object_ptr / observer_ptr to fix the remaining issues highlighted by the paper (common_reference_type between pointers and smart pointers).
— Strongly Favor
This facility helps users avoid getting raw pointers when they could just work directly with the smart pointers in question.
— Strongly Favor
The fewer .get() calls the better.
— Strongly Favor
Seem usable, low implementation cost.
— Weakly Favor
3.3. Poll 3: Apply naming changes ("notify_is.." into "is_notify" (etc.), and the FTM) and forward the updated P3255R3 to LWG for C++29 and as a DR up to C++20 (section 10 wording for DR, section 11 wording for C++29).
This is good metadata that can influence implementation choices.
— Strongly Favor
This is a useful facility that improves portability. I have use cases in mind already.
— Strongly Favor
This closes a gap in the standard library interface for atomics and is highly useful.
— Strongly Favor
Feels a little bit rushed because we did bring up a lot of issues (free functions, constexpr atomics, etc.) up during telecon that have not been discussed before, but all of those seem to be addressed by the paper properly.
— Weakly Favor
Seems like a decent thing to do. Allowing reasonable implementations is a good part of this paper. I think the paper should do a better job at showing what users are expected to do with different results of these functions, tho.
— Weakly Favor
There is a great risk of user assuming that lock-free on wait function would imply Address-free. If we want to guaranteed signal safety, we should simply do so.
— Weakly Against
3.4. Poll 4: Apply changes (apply section 8 wording option A, the rename of the member functions from "high_bits" / "low_bits" into "high" and "low", and remove the "3 recommended practice") and re-send the updated P3642R7 paper to LWG for C++29.
When will we have _umul128?
— Strongly Favor
This is essential to some safer math operations. We take our wins, wherever we can find them.
— Strongly Favor
I appreciate the addition of low-level arithmetic facilities like this. They address niche use cases, but solving those use cases without special support is not possible.
— Strongly Favor
This is a useful facility. The naming changes are good.
— Strongly Favor
Having members would allow me to store wider type, and mask it on access.
— Weakly Favor
The changes to apply make it better; they are too new to be strongly in favor of this paper.
— Weakly Favor
The renaming seem to decrease clarity. If people don’t like the "bit" part, the name should at least indicate what it is.
— Weakly Against