A vector can be empty; a string can be empty; a string_view can be empty;
even a std::array can be empty. So why block a std::span from being empty,
just because its extent isn't dynamic? I think this would end up blocking
some compile-time programming cases.

Speaking of which, it's annoying that this doesn't currently work, due to
data()'s implemenetation within std::array:

constexpr const std::array<int, 0> ar0{};
constexpr auto spanned_empty_array = std::span<const int, 0>{ar0};

See https://godbolt.org/z/L4-9r8

-- Jorg

ps Resending due to subscription issue with std-proposals

On Mon, Jul 1, 2019 at 5:45 AM Bjorn Reese <breese_at_[hidden]> wrote:

> The value of dynamic_extent was orginally -1 when the extent was signed,
> and now that the extent is unsigned it has become the maximum value
> (~0U).
>
> As the value of the extent is encoded in the mangled symbol names, the
> current value of dynamic_extent generates symbol names like (using
> clear() as an example)
>
> Itanium : _ZNKSt4spanIiLm4294967295EE5clearEv
> MSVC : ?clear@?$span_at_H$0PPPPPPPP@@std@@QEBAXXZ
>
> In other words, the default extent generates long symbol names.
>
> I propose that zero would be a better value for dynamic_extent. With
> this value the above-mentioned symbols becomes:
>
> Itanium : _ZNKSt4spanIiLm0EE5clearEv
> MSVC : ?clear@?$span_at_H$0A@@std@@QEBAXXZ
>
> In the concrete examples, this is a reduction of 9 and 7 characters
> respectively for each symbol.
>