Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<syncstream>: is_nothrow_move_assignable_v<osyncstream> is squirrelly 🐿️ #3355

Closed
StephanTLavavej opened this issue Jan 21, 2023 · 1 comment · Fixed by #3367
Closed
Labels
fixed Something works now, yay! LWG issue needed A wording defect that should be submitted to LWG as a new issue

Comments

@StephanTLavavej
Copy link
Member

WG21-N4928 [syncstream.osyncstream.overview] depicts basic_osyncstream& operator=(basic_osyncstream&&) noexcept;. However, it also depicts an exposition-only data member syncbuf_type sb; and [syncstream.syncbuf.assign] depicts basic_syncbuf& operator=(basic_syncbuf&& rhs); which is not noexcept (it calls emit()).

Our current implementation:

basic_osyncstream& operator=(basic_osyncstream&&) noexcept = default;

STL/stl/inc/syncstream

Lines 371 to 372 in fbed7ea

private:
syncbuf_type _Sync_buf;

STL/stl/inc/syncstream

Lines 109 to 110 in fbed7ea

basic_syncbuf& operator=(basic_syncbuf&& _Right) {
emit();

It seems to me that there's an LWG issue here, and that operator=(basic_osyncstream&&) should not be marked noexcept in the Standard (and in our implementation).

Programmer-archaeology: LWG-3498 "Inconsistent noexcept-specifiers for basic_syncbuf" (already merged into the WP) removed noexcept from operator=(basic_syncbuf&&) because it calls emit(). It seems to me that operator=(basic_osyncstream&&) was simply missed at that time.

Noticed while reviewing #3314.

@StephanTLavavej StephanTLavavej added the LWG issue needed A wording defect that should be submitted to LWG as a new issue label Jan 21, 2023
@frederick-vs-ja
Copy link
Contributor

LWG-3867 has been reported.

CaseyCarter added a commit to CaseyCarter/STL that referenced this issue Jan 29, 2023
@StephanTLavavej StephanTLavavej added the fixed Something works now, yay! label Feb 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed Something works now, yay! LWG issue needed A wording defect that should be submitted to LWG as a new issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants