Meta LWG issue: 2021-02 meeting

[StephanTLavavej]

(Previous meta-issue: #1446)

At the February 2021 virtual plenary meeting, the following LWG issues were resolved in the C++ Working Paper.

❔ Not yet analyzed

• Analyzed everything!

For each of these issues, we've determined whether they are:

✖️ 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-3495 constexpr launder makes pointers to inactive members of unions usable
• 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 - created PR Update comments for February 2021 LWG issues #1686:
  • LWG-3391 Problems with counted_iterator/move_iterator::base() const &
  • LWG-3433 subrange::advance(n) has UB when n < 0
    • Cited as LWG-3413 due to a typo
  • LWG-3490 ranges::drop_while_view::begin() is missing a precondition
  • LWG-3492 Minimal improvements to elements_view::iterator
• Already 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.

• Recorded in issue P0896R4 <ranges> #39 and PR Implement ranges::join_view #1436:
  • LWG-3500 join_view::iterator::operator->() is bogus
• Recorded in issue P0896R4 <ranges> #39:
  • LWG-3505 split_view::outer-iterator::operator++ misspecified

🪲 Not yet implemented

We should file a GitHub issue labeled LWG; see those existing examples.

• LWG-3494 Allow ranges to be conditionally borrowed
  • Filed issue LWG-3494 Allow ranges to be conditionally borrowed #1682.
• LWG-3502 elements_view should not be allowed to return dangling references
  • Filed issue LWG-3502 elements_view should not be allowed to return dangling references #1685.

[cpplearner]

"LWG-3391 Problems with counted_iterator/move_iterator::base() const &" is Already implemented.

STL/stl/inc/iterator

Line 1083 in 834baa6

_NODISCARD constexpr const _Iter& base() const& noexcept /* strengthened */ { // Per LWG-3391

STL/stl/inc/xutility

Line 3740 in 834baa6

_NODISCARD constexpr const iterator_type& base() const& noexcept /* strengthened */ { // Per LWG-3391

"LWG-3433 subrange::advance(n) has UB when n < 0" is Already implemented. (Note that due to a typo, this cited LWG-3413 "[fund.ts.v3] propagate_const's swap's noexcept specification needs to be constrained and use a trait".)

STL/stl/inc/xutility

Line 3576 in 834baa6

// Per LWG-3413, this has defined behavior when _Count < 0.

"LWG-3490 ranges::drop_while_view::begin() is missing a precondition" is Already implemented.

STL/stl/inc/ranges

Line 2199 in 834baa6

_STL_VERIFY(_Pred, "LWG-3490 forbids calling begin on a drop_while_view with no predicate");

"LWG-3492 Minimal improvements to elements_view::iterator" is Already implemented.

STL/stl/inc/ranges

Lines 2607 to 2608 in 834baa6

	constexpr void operator++(int) noexcept(noexcept(++_Current)) /* strengthened */ {
	// Constraint removed per LWG-3492

[StephanTLavavej]

For LWG-3495 "constexpr launder makes pointers to inactive members of unions usable", it appears that no compiler work is needed:

C:\Temp>type meow.cpp

#include <new>

struct A { int x; int y; };
struct B { float x; int y; };

union U {
  A a;
  B b;
};

constexpr A foo() {
  U u;
  int* byp = &u.b.y;
  static_assert(&u.b.y == static_cast<void*>(&u.a.y));
  u.a.y = 42;
  *std::launder(byp) = 13;
  return u.a;
}

extern constexpr A globA = foo();

C:\Temp>cl /EHsc /nologo /W4 /std:c++latest /c meow.cpp
meow.cpp
meow.cpp(20): error C2131: expression did not evaluate to a constant
meow.cpp(17): note: failure was caused by accessing a non-active member of a union
meow.cpp(17): note: see usage of 'U::a'

C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++latest /c meow.cpp
meow.cpp(20,20): error: constexpr variable 'globA' must be initialized by a constant expression
extern constexpr A globA = foo();
                   ^       ~~~~~
meow.cpp(16,22): note: assignment to member 'b' of union with active member 'a' is not allowed in a constant expression
  *std::launder(byp) = 13;
                     ^
meow.cpp(20,28): note: in call to 'foo()'
extern constexpr A globA = foo();
                           ^
1 error generated.