On Tue, Oct 3, 2023 at 1:38 PM Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Tue, Oct 3, 2023 at 2:21 AM Julien Jorge via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Regarding the description of nspan, you wrote:
>>
>> > We don't use span because present day code uses it differently. For
>> example you can not pass span into a function with the same type but
>> smaller length.
>>
>> It seems to me that this restriction can be lifted by changing the
>> constraint of 24.7.2.2.2 §19.2 from
>>
>> extent == dynamic_extent
>> || OtherExtent == dynamic_extent
>> || extent == OtherExtent
>>
>> to
>>
>> extent == dynamic_extent
>> || OtherExtent == dynamic_extent
>> || extent <= OtherExtent
>>
>> And adjusting §20-22 accordingly.
>>
>> I don't know why the current wording is the way it is but I think you
>> should take this in consideration in your proposal, as adapting
>> std::span seems easier than introducing a whole new type :)
>
>
> I agree that messing with `span` would be easier than introducing `nspan`. However, I don't think even messing with `span` (in this respect) is a good idea.
> IMHO it's clear that `span<int>` (with dynamic_extent) is the most correct type to use when your spans are of varying width. If you're using `span<int, 24>` in your API, it's because you intend to accept only spans of exactly 24 ints — no more and no less. If someone accidentally tries to pass you a `span<int, 42>` (with an extra 18 entries at the end that your API is going to silently ignore), that's a bug that should be caught at compile time!

I don't buy that.

The code consuming a span of 24 integers does not care if
*technically* there are a bunch more integers after it. Or a bunch
more integers *before* it. The conversion from a `span<int, 42>` to a
`span<int, 24>` is semantically harmless. There is no code that could
be broken by making that conversion implicit.