add c++20/23 constructors to basic_string_view about utility HOT 3 CLOSED

Given the feedback in boostorg/core#113, I kind of agree that the second constructor is probably a bad idea. The first one requires a modern standard library as it must only compile for contiguous iterators, which is C++20 I think. We currently don't have the infrastructure for this. I don't find the third one very useful, but fine, I guess.

from utility.

I agree on the third one.

Let's accept this as not desirable for now. In reality, the purpose of string_view alternatives outside the standard library are either supporting older compilers (so the missing c++20+ constructors are moot) or adding interoperability benefits (e.g. core::string_view).

from utility.

What about adding a more restricted version of the first constructor?

explicit constexpr basic_string_view(const_iterator first, const_iterator last);

This would at least provide compatibility with iterator_range's copy_range and as a result make string_view usable with string algorithms without needing to do a follow up conversion. Take for example this reduced example taken from code we're actually using (where we're forced to have an intermediate std::vector<boost::iterator_range<const char*>> to convert from):

auto do_split(boost::string_view str) {
    std::vector<boost::string_view> tokens;
    boost::split(tokens, str, [](const char c) { return c == ','; });
    return tokens;
}

This would seemingly provide partial forward compatibility with C++20's constructor without creating backwards compatibility problems in the future (that I can see).

Edit: I added this as a comment on boostorg/core#113 (comment). But I was unaware that's a different string_view than this one.

from utility.