add c++20/23 constructors to basic_string_view

[sehe]

The following constructors were added:

template <class It, class End> constexpr basic_string_view(It first, End last);
template <class R> constexpr basic_string_view(R&& r);
constexpr basic_string_view(std::nullptr_t) = delete;

(where It/End and R are subject to the usual restrictions)

People might expect these to be present on the Boost implementation.

[pdimov]

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2516r0.html.

[sehe]

Without clicking the link (on my phone) I assume this is this about the problems with these constructors?

If so is what does your comment mean? Can you clarify whether support for these features is rejected or postponed.

If rejected feel free to close!

[pdimov]

I'm not planning to add the relaxed range or iterator constructors unless there is a specific practical need arising from actual user code. Their absence is deliberate. string_view has too many implicit conversions as it is.

The nullptr_t one is an entirely separate topic. Probably should be added.

[sehe]

Thanks for the clarifications. I for one don't think the nullptr overload saves lives (beyond being more standards-similar). I'll close this issue

[sehe]

(Keeping around for the nullptr constructor.)

[Lastique]

FYI, C++23 has made the range constructor explicit in P2499. It's not as harmful this way.

[muggenhor]

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

explicit constexpr basic_string_view(const_iterator first, const_iterator last);

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

I'm not planning to add the relaxed range or iterator constructors unless there is a specific practical need arising from actual user code. Their absence is deliberate. string_view has too many implicit conversions as it is.

As for a use case from actual user code. I'm facing one right now. A reduced example of what we're trying to do:

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

Unfortunately split relies on a range constructor via iterator_range's copy_range. Adding an explicit range constructor that takes const_iterator would be sufficient to make that example functional.

[pdimov]

This issue is about boost::core::string_view (which already has such a constructor), not about boost::string_view.

[muggenhor]

Ah, I was unaware there were multiple copies of string_view. I'll switch to commenting on the utility version of it.