On Thu, Apr 4, 2024 at 5:57 AM Hewill Kang via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi all,
>
> I wrote a draft for C++26 range adaptor views::delimit, you can see it
> here
> https://isocpp.org/files/papers/D3220R0.html
> Since this is a draft, there may be some missing points that have not been
> considered, or there is room for improvement in wording.
> Comments are welcome.
>
> Thanks,
> Hewill
>

Hey Hewil,

I didn't understand the argument for why not just define delimit as
take_while. You mean three points there:

"First, it's unclear whether to save v just in a lambda or use
bind_front(ranges::not_equal_to, v) for a more general purpose, which
introduces extra indirection anyway with one more layer of wrapping."

I'm not sure what extra indirection you mean? I think bind_front is better,
since then you can views::delimit(v) or views::delimit(std::ref(v)).

"Second, we need to check that v can be forwarded into lambda, which
requires additional constraints for the adaptor's call operator. Moreover,
we also need to ensure that e != v is a valid expression to avoid hard
errors in the lambda body, which ultimately makes the function signature
complex and ugly."

Yes, but you need all those same constraints anyway, right?

"Finally, if the bottom layer of views::delimit is take_while_view, then
the former will also have a pred() member which returns the internal
lambda, this can lead to untold confusion for the user."

I am, ironically, confused by this claim. If we just say delimit(v) is
shorthand for take_while(bind_front(...)) then I think it's pretty clear
what pred() means, right?

Thanks for writing this up,

Barry