span: Implement solution to LWG-3255

[Michael Schellenberger Costa (miscco)]

Description

This implements the solution to LWG-3255.

I dont know how, but it seems some superfluos template argument slippend into one of the legacy constructors, which has been cleaned up too.

Checklist

Be sure you've read README.md and understand the scope of this repo.

If you're unsure about a box, leave it unchecked. A maintainer will help you.

• Identifiers in product code changes are properly _Ugly as per
  https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
• The STL builds successfully and all tests have passed (must be manually
  verified by an STL maintainer before automated testing is enabled on GitHub,
  leave this unchecked for initial submission).
• These changes introduce no known ABI breaks (adding members, renaming
  members, adding virtual functions, changing whether a type is an aggregate
  or trivially copyable, etc.).
• These changes were written from scratch using only this repository,
  the C++ Working Draft (including any cited standards), other WG21 papers
  (excluding reference implementations outside of proposed standard wording),
  and LWG issues as reference material. If they were derived from a project
  that's already listed in NOTICE.txt, that's fine, but please mention it.
  If they were derived from any other project (including Boost and libc++,
  which are not yet listed in NOTICE.txt), you must mention it here,
  so we can determine whether the license is compatible and what else needs
  to be done.

[Michael Schellenberger Costa (miscco)]

I hate it when preexisting bugs -- introduced by myself -- interfere with me mindlessly copying code around.

That totally breaks my workflow

[Michael Schellenberger Costa (miscco)]

I made clang-format happy.

Besides thatI noticed that the non-concepts version of the array-constructor was missing the type_identity that Stephan T. Lavavej (@StephanTLavavej) added for its concepts sibling.

Given that that the deduction guides for arrays are the same with/without concepts I believe this should also be added.

[Casey Carter (CaseyCarter)]

Besides that I noticed that the non-concepts version of the array-constructor was missing the type_identity that Stephan T. Lavavej (@StephanTLavavej) added for its concepts sibling.

Given that that the deduction guides for arrays are the same with/without concepts I believe this should also be added.

It shouldn't be necessary. In the concepts case, we need to prevent the constructor from participating in CTAD because it will be chosen over the deduction guide due to the "more-constrained is better" tie-breaker rule. For non-concepts, overload resolution makes it to the "deduction guide is better" rule and correctly prefers the guide to the constructor.

(Also, the tests were passing without it.)

[Casey Carter (CaseyCarter)]

Should we add test coverage for the problematic initialization in the issue?

std::array<int*, 2> a = {nullptr, nullptr};
std::span<const int* const> s{a};

a static_assert somewhere in P0122R7_span/test.cpp would suffice.

Otherwise this LGTM.

[Stephan T. Lavavej (StephanTLavavej)]

I am confused - this PR no longer contains product changes. Was it damaged?

[Casey Carter (CaseyCarter)]

Michael Schellenberger Costa (@miscco) Looks like you force pushed and/or rebased too hard. (FWIW, I generally merge master into my branch when necessary rather than rebasing my branch onto master once there's a PR out so I can avoid force pushing.)

(I think https://github.com/CaseyCarter/STL/tree/span_rebuild has all the commits in the right order if that helps.)

[Michael Schellenberger Costa (miscco)]

It seems you should be sure that you do a

git rebase upstream/master

and not

git reset upstream/master

[Stephan T. Lavavej (StephanTLavavej)]

I've submitted a Microsoft-internal PR for this; please don't push any more changes to this branch, and we should be able to merge it very soon. :-)

[Stephan T. Lavavej (StephanTLavavej)]

Michael Schellenberger Costa (@miscco), thanks again for improving span usability! 😸😸