On Tue, Jan 30, 2024 at 11:45 AM Hewill Kang <hewillk_at_[hidden]> wrote:

> I support the general direction of making the Ranges view types more
>> consistent; but why is your proposal not simply to change
>> https://eel.is/c++draft/view.interface
>> like this?
>
>
> I believe this does not solve the original issue.
> Let’s leave aside the issue of constraints relying on themselves this may
> cause.
>

`ranges::empty(derived())` is not the same thing as
`ranges::empty(*this)`... oh, I see, I meant the equivalent of
`ranges::empty(*base()*)` — that is, if the *actual thing* provides
`empty()` then we should use that. But view_interface is CRTP — not an
adaptor *over* the actual thing but a substrate *contributing to* the
actual thing. My suggestion doesn't apply, then.



> In my original example, the type of s | std::views::as_rvalue is as_rvalue_view<subrange<istream_iterator<int>,
> istream_iterator<int>>>, so derived() returns as_rvalue_view, and
> ranges::empty cannot be applied to this as_rvalue_view since it is
> neither forward_range nor sized_range.
>

But in this case my intuition was correct: `ranges::empty(r)` doesn't
require `r` to be forward_range or sized_range. It correctly works on
anything with a `.empty()` member.
https://eel.is/c++draft/range.prim.empty

So the proposal is to make sure that every Ranges view type with a
`.size()` also has a `.empty()`, is that correct (now)?
And the only viable way to do that is to add the `.empty()` method to the
specification of each individual view (take_view, drop_view, etc.), just
like we already do for `.size()` today?

–Arthur