Skip to content

[Motions 2026 03 lwg 2] P4146R0 C++ Standard Library Immediate Issues#8935

Open
burblebee wants to merge 37 commits intomainfrom
motions-2026-03-lwg-2
Open

[Motions 2026 03 lwg 2] P4146R0 C++ Standard Library Immediate Issues#8935
burblebee wants to merge 37 commits intomainfrom
motions-2026-03-lwg-2

Conversation

@burblebee
Copy link
Copy Markdown
Contributor

Fixes #8836.

@burblebee burblebee marked this pull request as ready for review April 9, 2026 14:26
@eisenwave eisenwave added this to the post-2026-03 milestone Apr 12, 2026
@tkoeppe tkoeppe force-pushed the motions-2026-03-lwg-2 branch from 29c2e35 to ed9db42 Compare April 12, 2026 20:19
@tkoeppe tkoeppe force-pushed the motions-2026-03-lwg-2 branch from ed9db42 to 45d9c2d Compare April 12, 2026 20:21
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).
@tkoeppe tkoeppe force-pushed the motions-2026-03-lwg-2 branch from 45d9c2d to b87b2ae Compare April 13, 2026 22:43
is \tcode{true}.
\end{itemize}

%FIXME: Is this supposed to be part of the Remarks clause?
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

@jwakely jwakely left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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()}.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the change to use "Finally, returns ..." below, would it make sense to be consistent here?

Suggested change
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}}%
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
is \tcode{true}
is \tcode{true},

Otherwise, it is expression-equivalent to
\tcode{\exposid{MANDATE-NOTHROW}(rcvr.set_value(vs...))}.

\mandates
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Suggested change
\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
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +5683 to +5684
@\exposid{future-operation}@(StatePtr state, Rcvr rcvr) noexcept // \expos
: @\exposid{rcvr}@(std::move(rcvr)), @\exposid{state}@(std::move(state)), @\exposid{inner}@(this)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we care about the shadowed named here?

Suggested change
@\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}@);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
@\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}%
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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}%
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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()}
Copy link
Copy Markdown
Member

@jwakely jwakely Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be a closed range, not half-open, and the + should be math font not code font:

Suggested change
\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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[2026-03 LWG Motion 2] P4146R0 C++ Standard Library Immediate Issues

3 participants