(Previous meta-issue: #3437)
At the June 2023 meeting, the following LWG issues were resolved in the C++ Working Paper.
❔ Not yet analyzed
(Nothing here!)
❌ Not applicable
If an issue requires no action from implementers, we mark it as N/A. Categories:
- Pure wording clarifications with nothing to implement (these can be changes to non-normative text like examples and informative notes, or wording cleanups to normative text that don't impact observable behavior)
- Something that increases the restrictions placed on users, but implementers aren't expected to enforce those restrictions
- Fixes for obviously broken wording, where implementers would have done the right thing anyways
😸 Already implemented
Sometimes we cite LWG issues in product code comments as we're implementing their proposed resolutions. When the resolutions are officially accepted, we should remove the citations (as the default assumption is that we're implementing what the Standard says). If something is especially subtle, we can convert the citation to mention the relevant Standard section. Sometimes we should add test coverage - e.g. when the Standard begins requiring something that we were already doing, but weren't explicitly testing for.
-
Already implemented, comments need to be removed and messages need to cite the Standard
-
Implemented without comments
🩹 Patches an unimplemented feature
We should record this LWG issue in the GitHub issue tracking the feature. That way, we'll remember to verify it, but it doesn't represent net new work.
🐞 Not yet implemented
(Previous meta-issue: #3437)
At the June 2023 meeting, the following LWG issues were resolved in the C++ Working Paper.
❔ Not yet analyzed
(Nothing here!)
❌ Not applicable
If an issue requires no action from implementers, we mark it as N/A. Categories:
spandestructor is redundantlynoexceptstd::fexcept_top' should be in [zombie.names]ranges::enumerate_viewoperator[]for sequence containerstemplate<class X> constexpr complex& operator=(const complex<X>&)has no specification😸 Already implemented
Sometimes we cite LWG issues in product code comments as we're implementing their proposed resolutions. When the resolutions are officially accepted, we should remove the citations (as the default assumption is that we're implementing what the Standard says). If something is especially subtle, we can convert the citation to mention the relevant Standard section. Sometimes we should add test coverage - e.g. when the Standard begins requiring something that we were already doing, but weren't explicitly testing for.
Already implemented, comments need to be removed and messages need to cite the Standard
enumerate_view::iterator::operator-should benoexceptenumerate_view::iterator::operator-should benoexcept#3780.std::expected<void, E>::value()also needsEto be copy constructiblestd::expected<void, E>::value()also needsEto be copy constructible #3779.Implemented without comments
basic_stringandbasic_string_viewFor some historical reason, we didn't reject erroneous uses in all modes.
STL/stl/inc/xstring
Lines 2334 to 2335 in 15aea98
allocate_at_leaststd::expectedmonadic ops with move-onlyerror_type🩹 Patches an unimplemented feature
We should record this LWG issue in the GitHub issue tracking the feature. That way, we'll remember to verify it, but it doesn't represent net new work.
flat_foois missing allocator-extended copy/move constructors<flat_map>#2910 and P1222R4<flat_set>#2912.generator::promise_type::yield_value(ranges::elements_of<Rng, Alloc>)should not benoexcept<generator>: Synchronous Coroutine Generator For Ranges #2936.formattable's definition is incorrect🐞 Not yet implemented
atomic<shared_ptr<T>> a; a = nullptr;atomic<shared_ptr<T>> a; a = nullptr;#3782.lazy_split_view::outer-iterator'sconst-converting constructor isn't settingtrailing_empty_lazy_split_view::outer-iterator'sconst-converting constructor isn't settingtrailing_empty_#3781.