You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the November 2023 meeting, the following LWG issues were resolved in the C++ Working Paper.
❔ Not yet analyzed
Remaining issues:
All done!
❌ 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)
LWG-3957 [container.alloc.reqmts] The value category of v should be claimed
LWG-3965 Incorrect example in [format.string.escaped]/3 for formatting of combining characters
Our implementation agrees with the corrected example.
Something that increases the restrictions placed on users, but implementers aren't expected to enforce those restrictions
LWG-3990 Program-defined specializations of tuple and variant can't be properly supported
Fixes for obviously broken wording, where implementers would have done the right thing anyways
LWG-3431<=> for containers should require three_way_comparable<T> instead of <=>
LWG-3951 [expected.object.swap]: Using value() instead of has_value()
😸 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
LWG-3949atomic<bool>'s trivial destructor dropped in C++17 spec wording
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.
LWG-3892 Incorrect formatting of nested ranges and tuples
(Previous meta-issue: #3778)
At the November 2023 meeting, the following LWG issues were resolved in the C++ Working Paper.
❔ Not yet analyzed
❌ 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)
span
element access invalidationv
should be claimedSomething that increases the restrictions placed on users, but implementers aren't expected to enforce those restrictions
tuple
andvariant
can't be properly supportedFixes for obviously broken wording, where implementers would have done the right thing anyways
<=>
for containers should requirethree_way_comparable<T>
instead of<=>
value()
instead ofhas_value()
😸 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.
atomic<bool>
's trivial destructor dropped in C++17 spec wordingatomic<bool>
's trivial destructor dropped in C++17 spec wording #4164.any_cast<void>
static_assert
s for this.possibly-const-range
andas-const-pointer
should benoexcept
🩹 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.
full_extent_t
andfull_extent
submdspan
#3807.<flat_meow>
doesn't providestd::begin/end
<flat_map>
#2910 and P1222R4<flat_set>
#2912.🐞 Not yet implemented
Filed a GitHub issue labeled LWG
common_iterator
should handle integer-class difference typescommon_iterator
should handle integer-class difference types #4163.subtract_with_carry_engine<uint16_t>
supposed to work?subtract_with_carry_engine<uint16_t>
supposed to work? #4162.inout_ptr
will not update raw pointer to nullinout_ptr
will not update raw pointer to null #4160.const_iterator_t
should be reworkedconst_iterator_t
should be reworked #4161.adjacent_transform_view::base()
adjacent_transform_view::base()
#4165.iter_move
forcommon_iterator
andcounted_iterator
should returndecltype(auto)
iter_move
forcommon_iterator
andcounted_iterator
should returndecltype(auto)
#4157.mdspan::operator[]
should not copyOtherIndexTypes
mdspan::operator[]
should not copyOtherIndexTypes
#4166 to double-check.iota_view
should provideempty
iota_view
should provideempty
#4159.PR out for review
The text was updated successfully, but these errors were encountered: