While a span
can be constructed from a range, a string_view
cannot be constructed from a range of chars.
Thus, for example, the following code is required:
// assume chars_span is a span of chars
std::cout << std::string_view(chars_span.data(), chars_span.size());
// or:
std::cout << std::string_view(chars_span.begin(), chars_span.end());
Instead of a simpler range-syntax that is not supported:
std::cout << std::string_view(chars_span);
Is there a reason for not having a constructor for string_view
that accepts a range of chars, or was it just overlooked or not considered important enough?
P1391r3 proposed this, though this was dropped in the version that was eventually adopted for C++20: P1391r4. The reason for the drop unfortunately is completely absent from the paper (indeed, the paper does not even mentioned that it was dropped).
However, a follow-up paper, P1989R0 presents the issue as what happens if we had a type like this (I modified the example slightly):
Here,
buffer
is convertible tostring_view
. But the way in which it is convertible tostring_view
differs in the way in whichstring_view
's range constructor would do it (the former gives you two chars, the latter gives you 42). As far as I am aware, nobody has actually pointed out the existence of such types.Nevertheless, the direction was to ensure that those types continue to just work, so the new paper has a more complicated set of constraints for that particular constructor.
A more interesting example would be something like:
Any kind of straightforward range-based reasoning would allow the conversion from
ci_string
tostd::string
. Aci_string
is a perfectly good contiguous range ofchar
, without any weird conversion issues like thebuffer
type from earlier. But whileci_string
should be convertible tobasic_string_view<char, case_insensitive_traits>
, we probably wouldn't want to avoid it being convertible to just normalstring_view
. That's unlikely to be intended, so it's something that we need to try to guard against.This case is much more motivating for me than the
buffer
case.