Hello,

Il 16/12/23 14:40, Hewill Kang via Std-Proposals ha scritto:
> The problem is that currently if a |subrange| is returned in
> |<ranges>|/|<algorithm>|, it is constructed in the form of
> |subrange{it1, it2}|, even though we have increment from |it1| to |it2|,
> which means we already know how far is |it1| from |it2|.
>
> I'm curious if it would be more valuable if we returned |subrange{it1,
> it2, d}|, although this might introduce an extra variable |d| to track
> the distance. The advantage of this is that the returned |subrange|s are
> always |sized_range|, which makes the corresponding algorithm return
> more information.
>
> In |<ranges>|, some views like |split_view| or |chunk_view| can also
> benefit from this because the |subrange| they split will always be a
> |sized_range|.
>
> What do you think? Is this worth considering as an enhancement? Or is
> this a bad idea?

Assuming that the algorithms you're talking about already do keep track
of the size, or it's super cheap for them to do so, then I would say
that it's a good idea, as throwing away useful information is never a
smart thing to do. It follows the precedent set for instance by
https://wg21.link/P0646R1 .

But anyhow, here's the proverbial spanner in the works: the change
you're proposing would break ABI and API, so I doubt it's going to fly...


My 2 c,

-- 
Giuseppe D'Angelo