On 7/1/19 9:48 PM, Arthur O'Dwyer wrote:

> Sure, but you could make the same argument for removing /*every*/ extent
> except dynamic_extent — that is, making std::span work just like
> std::string_view. That would certainly be a simpler design.

That is not what I am proposing.

> But the std::span designers thought that every possible dynamic extent
> should have a matching compile-time static extent. It would be very
> weird if "0" were the one exception to the compile-time rule.

We already have that exception for the current value of dynamic_extent.

When std::span was originally designed with a signed extent, the value
for dynamic_extent was indeed outside the the domain for static extents,
but that changed when it was changed to an unsigned type.

I am simply proposing to change the value to something that may bring
us other benefits.

> template<class T, auto N>
> void test(std::array<T, N>& arr)
> {
> std::span<T, N> span(arr);
> static_assert(span.size() == N); // notice the static_assert
> }
> template void test(std::array<int, 42>&); // OK today
> template void test(std::array<int, 0>&); // OK today, but you propose
> to break it

template void test(std::array<int,
std::numeric_limits<std::size_t>::max()>&); // NOT OK today

> And your proposal's only motivation is the size of the debug symbols?

That is the primary motivation, as I am assuming that most spans in the
future will have dynamic extent because it is the default. So far I have
seen no real disadvantage to changing the value.