The default constructor of a static span requires _Extent == 0 so SFINAE it out rather than using a static_assert
Details
- Reviewers
mclow.lists EricWF miscco CaseyCarter - Group Reviewers
Restricted Project - Commits
- rG79941086fba3: [libc++][span] SFINAE span default constructor on Extent == 0
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 43436 Build 44289: arc lint + arc unit
Event Timeline
What is the benefit to the user to have this constructor SFINAE away?
With static_assert we can craft an error message.
Hm, this fixes a todo that was written by you..
No seriously I believe this is indeed a correctness issue.
First the standard marks this as a "Constraint". As far as my standardese goes this requires that this function should be SFINAEd out.
Also if we would not remove the default constructor span<T, 2> would fulfill the`default_constructible` concept although it does not.
So I believe there is no alternative to removing that constructor.
That is a compelling argument.
Since you pointed this out, we probably need a test showing that this is true for:
- dynamically sized spans
- statically sized spans of size 0
- but NOT for statically sized spans of size > 0
Library concepts are not yet implemented.
I had a look at it over the weekend. The problem is that requires expressions are not yet implemented so we cannot even add those concepts yet. I didnt find out how to pass -fconcepts to gcc-9 in LIT and was too lazy to build everything on windows with MSVC.
So I would keep them as a todo?
libcxx/test/std/containers/views/span.cons/default.pass.cpp | ||
---|---|---|
17 | Late comment: <span> isn't guaranteed to export __cpp_lib_concepts; this should include <version> before checking __cpp_lib_concepts. |
libcxx/test/std/containers/views/span.cons/default.pass.cpp | ||
---|---|---|
17 | I added it one tooth-brushing with my kids ago. That feels like an eternity but if it qualifies as late... |
LGTM. (Resigning as reviewer rather than approving to avoid confusing the folks who are actually authorized to approve.)
Does this really need concepts?
libcxx/include/span | ||
---|---|---|
212–213 | We don't use concepts anywhere else in the library. Why are you not using SFINAE instead? What happens when you include this file when requires isn't supported? |
You are absolutely right.
While it is technically correct as both span and concepts are a C++20 feature I belive this change is not helpful. It is just soo much better :(
That said, we should switch to concepts once the library concepts and ranges are fully available as that is needed for conformance of the range based contructors.
How do I revert an update in phabricator?
All concerns by other reviewers seem to have been addressed, feel free to move forward. Don't apply clang-format changes. Thanks!
I'm committing this, but I'm removing concepts from the tests.
Please don't require features we don't implement like that, it's just pointless. You basically have dead code in your test as it stands.
We don't use concepts anywhere else in the library. Why are you not using SFINAE instead?
What happens when you include this file when requires isn't supported?