C++ Logo

std-proposals

Advanced search

Re: [span] Value of dynamic_extent

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Mon, 1 Jul 2019 15:48:33 -0400
On Mon, Jul 1, 2019 at 3:39 PM Bjorn Reese via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 7/1/19 8:59 PM, Andrey Semashev via Std-Proposals wrote:
> > I think, std::array allows zero extent. std::span constructor from such
> > an array should produce an empty span rather than a span with dynamic
> > extent.
>
> A span with dynamic extent spanning an empty array will still be an
> empty span:
>
> std::array<int, 0> array;
> std::span<int> span(array);
> assert(span.size() == 0);
>

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.

   std::array<int, 42> array;
> std::span<int> span(array);
> assert(span.size() == 42);
>

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.

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

And your proposal's only motivation is the size of the debug symbols? The
STL has *way* worse problems elsewhere with huge debug symbols, IMHO.
Unless you've measured this somehow and have numbers showing the proposed
improvement?

HTH,
–Arthur

Received on 2019-07-01 14:50:33