The alternative, of course, is for the mangler to be a little smarter.

In the library side, we have a beautiful and powerful typesystem - so using
a token value for a special case is not exactly a well thought out
approach, specifically because the choice of token has ramifications. The
aim, given the approach taken, is then to reduce the impact of those
ramifications.

Following the principle of least astonishment, zero as a token makes
significantly less sense than uint max. Whilst there is technically more
utility to having a span of uint max size (because there is precisely zero
utility in having one of zero size), zero is much more likely to appear as
a result of application of a general method, e.g. via recursion, or as the
result of some calculation, in normal circumstances. An edge case it may be
(and possibly should be, given the context), but if you're hitting uint max
with those things then you're either doing something wrong, using the wrong
tool for the job, or you're doing something highly specialised and you
already know what you're doing.

At the end of the day, there's nothing mathematically special about uint
max [citation needed]. Zero, however, is extremely mathematically
significant, and it appears as a result of more calculations than any other
integral number [citation needed], and is a common terminating case for
recursive methods. Thus things should not break at zero just because of a
design decision, especially one motivated by trivialities such as mangling.




On Mon, 1 Jul 2019, 20:48 Arthur O'Dwyer via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>