gsl::span P1976R2 implemenation #887
Conversation
|
I'll keep this in draft form until I get clean builds of Appveyor and Travis, I'm guessing there will be some issues that pop up with some of the older compilers. |
| template <std::size_t Ext> | ||
| constexpr extent_type<Ext>::extent_type(extent_type<dynamic_extent> ext) | ||
| { | ||
| Expects(ext.size() == Ext); | ||
| } | ||
|
|
There was a problem hiding this comment.
I'm unsure whether this actually needs to be an out-of-line definition. My understanding is that member function bodies aren't instantiated until needed (this is what lets list<T>::sort() require op< from T only if sort() is actually called). So you should be able to define this within the class definition, without fear of prematurely instantiating the primary template for extent_type<dynamic_extent> before the explicit specialization has been seen. But if you're especially concerned about that, I think I would recommend declaring the primary template and then declaring the explicit specialization, so you can definitely define this member function within the class definition.
include/gsl/span
Outdated
| @@ -420,18 +420,28 @@ public: | |||
| constexpr span() noexcept : storage_(nullptr, details::extent_type<0>()) | |||
| {} | |||
|
|
|||
| constexpr span(pointer ptr, size_type count) noexcept : storage_(ptr, count) | |||
| template<std::size_t SpanExtent = Extent, std::enable_if_t<SpanExtent != gsl::dynamic_extent, int> = 0> | |||
There was a problem hiding this comment.
Within the gsl namespace, you should never need to qualify gsl::dynamic_extent - you can simply say dynamic_extent without fear of ambiguity with std::dynamic_extent (even if the user has using namespace std;). This is because unqualified name lookup will start within gsl and find the declaration there - it won't reach into the global namespace and won't consider any using-directives/using-declarations there either. The same is true for all non-functions in gsl (e.g. types, alias templates, variable templates, etc.).
There was a problem hiding this comment.
It looks like there's a mix of dynamic_extent and gsl::dynamic_extent all throughout this file. I'll file an issue and separate PR to make it more cohesive.
|
Thanks again @CaseyCarter and @StephanTLavavej for the code review! |
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1976r2.html
@CaseyCarter would you mind taking a look at this?