[Motions 2026 03 lwg 2] P4146R0 C++ Standard Library Immediate Issues#8935
[Motions 2026 03 lwg 2] P4146R0 C++ Standard Library Immediate Issues#8935
Conversation
29c2e35 to
ed9db42
Compare
Fixes NB RU 268 (C++26 CD).
…e first range is input and one of the ranges is empty
…lity Fixes NB US 135-216, US 136-217 (C++26 CD).
…g std::inplace_vector
ed9db42 to
45d9c2d
Compare
Fixes NB US 242-372 (C++26 CD).
Fixes NB US 257-382 (C++26 CD). [task.state]p5 Didn't insert a new paragraph (text belongs with the \effects clause).
… min/max considerations Fixes NB US 142-236 (C++26 CD).
Fixes NB US 249-379 (C++26 CD).
… requests to spawned work [exec.spawn.future] "receiver" in struct "future-operation" renamed to "receiverx" due to concept of same name.
[set.intersection] Turned "skipped" into an indexed definition to match that of LWG4544.
Fixes NB GB 07, GB 11 (C++26 CD).
… memory contents
…to concat_view Fixes NB FR 025-246 (C++26 CD).
Fixes NB US 139-232 (C++26 CD).
Fixes NB US 81-149 (C++26 CD).
Fixes NB US 75-138 (C++26 CD).
45d9c2d to
b87b2ae
Compare
| is \tcode{true}. | ||
| \end{itemize} | ||
|
|
||
| %FIXME: Is this supposed to be part of the Remarks clause? |
There was a problem hiding this comment.
Yes, but it's OK as a separate paragraph that follows the existing Remarks: paragraph (as discussed on mattermost)
| using @\exposid{range-to-alloc-type}@ = | ||
| pair<const typename ranges::range_value_t<Range>::first_type, | ||
| typename ranges::range_value_t<Range>::second_type>; // \expos | ||
| pair<const @\exposid{range-key-type}@<Range>, |
There was a problem hiding this comment.
N.B. The P/R in the issue shows add_const_t here, but that was changed to const by #7851 so the conflict here has been resolved correctly.
jwakely
left a comment
There was a problem hiding this comment.
Some changes, some comments not requiring actions, and some questions.
| Let \tcode{\placeholder{st}} be \tcode{get_stop_token(get_env(\exposid{rcvr}))}. | ||
| Initializes \tcode{\placeholder{prom}.\exposid{token}} and | ||
| \tcode{\placeholder{prom}.\exposid{source}} such that | ||
| After that invokes \tcode{\exposid{handle}.resume()}. |
There was a problem hiding this comment.
I like the change to use "Finally, returns ..." below, would it make sense to be consistent here?
| After that invokes \tcode{\exposid{handle}.resume()}. | |
| Finally, invokes \tcode{\exposid{handle}.resume()}. |
| After that invokes \tcode{\exposid{handle}.resume()}. | ||
| \end{itemdescr} | ||
|
|
||
| \indexlibrarymember{\exposid{get-stop-token}}{task::\exposid{state}}% |
There was a problem hiding this comment.
Should this exposition-only member function be indexed? Huh, we do it for lots of others ... OK then.
| \effects | ||
| If | ||
| \tcode{\libconcept{same_as}<decltype(declval<stop_source_type>().get_token()), decltype(get_\linebreak{}stop_token(get_env(\exposid{rcvr})))>} | ||
| is \tcode{true} |
There was a problem hiding this comment.
| is \tcode{true} | |
| is \tcode{true}, |
| Otherwise, it is expression-equivalent to | ||
| \tcode{\exposid{MANDATE-NOTHROW}(rcvr.set_value(vs...))}. | ||
|
|
||
| \mandates |
There was a problem hiding this comment.
Do we want a new paragraph for this? The issue doesn't request it, and some other places in [exec] have Mandates attached to other paragraphs (or list items), so I'm not sure.
| \mandates | |
| \pnum | |
| \mandates |
If we do it here, we should do it below as well.
(Maybe our library element macros like \mandates and \expects should have an implicit \pnum, and then have a raw form for cases like this and [structure.specifications] and [exec.get.fwd.progress] p2 where we don't want a new paragraph and a pnum.)
| using @\exposid{stop-callback-t}@ = // \expos | ||
| stop_callback_for_t<@\exposid{stop-token-t}@, @\exposid{callback}@>; | ||
|
|
||
| struct @\exposid{receiverx}@ { // \expos |
There was a problem hiding this comment.
I don't love just appending 'x' to disambiguate this from the receiver concept. Is it a problem because we have scripts that complain that \libconcept is not used on it? Could we fix the scripts to ignore \exposid{foo} so we can reuse the name? Or maybe make this receiver-t instead? That's not ideal because we also have receiver_t but at least they're not identical.
| @\exposid{future-operation}@(StatePtr state, Rcvr rcvr) noexcept // \expos | ||
| : @\exposid{rcvr}@(std::move(rcvr)), @\exposid{state}@(std::move(state)), @\exposid{inner}@(this) |
There was a problem hiding this comment.
Do we care about the shadowed named here?
| @\exposid{future-operation}@(StatePtr state, Rcvr rcvr) noexcept // \expos | |
| : @\exposid{rcvr}@(std::move(rcvr)), @\exposid{state}@(std::move(state)), @\exposid{inner}@(this) | |
| @\exposid{future-operation}@(StatePtr s, Rcvr r) noexcept // \expos | |
| : @\exposid{rcvr}@(std::move(r)), @\exposid{state}@(std::move(s)), @\exposid{inner}@(this) |
I don't think we need to change anything, it's fine as is.
| } | ||
| } | ||
|
|
||
| @\exposid{state}@.release()->@\exposid{consume}@(@\exposid{innex}@); |
There was a problem hiding this comment.
| @\exposid{state}@.release()->@\exposid{consume}@(@\exposid{innex}@); | |
| @\exposid{state}@.release()->@\exposid{consume}@(@\exposid{inner}@); |
| are considered \term{skipped}. | ||
| If $N < M$, a non-copied element is also considered skipped | ||
| if it compares less than the $(N + 1)^\text{th}$ element | ||
| \indextext{element!skipped}% |
There was a problem hiding this comment.
This definition is local to this function, do we need to index it?
| are included in the sorted difference, in order. | ||
| Of those equivalent elements, | ||
| the first $\min(m, n)$ elements in both ranges | ||
| \indextext{element!skipped}% |
There was a problem hiding this comment.
Same question here, do we need to index this?
| returns an object \exposid{V} such that | ||
| \tcode{\exposid{V}.data()[\exposid{V}.size()]} equals \tcode{'\textbackslash 0'}. | ||
| Each element of the range | ||
| \tcode{\exposid{V}.data() +} \range{0}{\exposid{V}.size()} |
There was a problem hiding this comment.
This should be a closed range, not half-open, and the + should be math font not code font:
| \tcode{\exposid{V}.data() +} \range{0}{\exposid{V}.size()} | |
| $\tcode{\exposid{V}.data()} + \crange{0}{\exposid{V}.size()}$ |
We have the \countedrange macro for X+[0,n) but it always uses a half-open range. We could add \countedcrange for X+[0,n] but I think this is the only place we need it.
Fixes #8836.