On Tue, 2023-10-03 at 14:01 -0400, Jason McKesson via Std-Proposals
wrote:
> 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.

So which of the two should happen? Should elements at the front or at
the back be dropped in the conversion?

IMO this conversion makes as much sense as a similar conversion from
`tuple<int&, int&>` to `tuple<int&>`.

> There is no code that could
> be broken by making that conversion implicit.