Why doesn't std::string_view have assign() and clear() methods?

Question

The implementation of these methods seems straightforward to me and they would make usage of std::string and std::string_view more interchangeable. After all, std::string_view has constructors which leave the object in the same state as these methods would. One could workaround the missing methods like this:

std::string s {"abcd"};
std::string_view v {s.c_str()};
std::cout << "ctor:   " << v << std::endl; // "abcd"
v = {s.c_str() + 1, 2};
std::cout << "assign: " << v << std::endl; // "bc"
v = {nullptr}; // or even v = {};
std::cout << "clear:  " << v << std::endl; // ""

So, what are the reasons for not including these two obvious methods in the standard?

UPDATE: One general question in your comments seems to be "What's the point?", so I'll give you some context. I'm parsing a large string with the result being a structure of substrings. That result structure is a natural candidate for string views, so I don't have to copy all those strings, which are even overlapping. Part of the result are maps to string views, so I might need to construct them empty when I get the key and fill them later when I get the value. While parsing I need to keep track of intermediate strings, which involves updating and resetting them. Now they could be replaced by string views as well, and that's how I happened on those missing functions. Of course I could continue using strings or replace them by plain old ptr-ptr or ptr-size pairs, but that's exactly what std::string_view is for, right?

Answer 1

The std::string interface has a bad reputation due to its blown API, that's why std::string_view is very unlikely to get as many methods as std::string just because it's convenient or makes the two types more interchangeable.

But more important, these types aren't meant to be interchangeable. What does it mean for view on a container of characters to be "cleared"? As clear() is present on all STL containers and does something meaningful, having a std::string_view::clear() would be quite confusing.

In addition, a view on some data is meant for temporary consumption, e.g. a read-only function parameter. Why would you want to assign to it anyway? Here is an example function signature that uses std::string_view:

// Called e.g. with "x86_64-Darwin-16.7.0"
std::string_view extractOSName(std::string_view configStr)
{
    // Parse input, return a new view. Lifetime/ownership managed by caller.
    // No need to re-assign anything, let alone "clearing" them.
}

Answer 2

This is only ever really going to be speculation, but general concensus seems to be that these operations would be middlingly unclear.

Personally I think "clearing a view" makes perfect sense (and let's also not forget that remove_prefix and remove_suffix exist! Though see below...), but I also agree that there are other interpretations, which may be common, which make less sense. Recall that string_view is intended to complement const std::string&, not std::string, and neither of the functions you name is a part of std::string's constant interface.

To be honest, the fact that we need this conversation at all is, itself, probably a good reason to just not have the function in the first place.

From the final proposal for string_view, the following passage is not about assign or clear specifically but does act as a relevant view [lol] into the minds of the committee on this subject:

s/remove_prefix/pop_front/, etc.

In Kona 2012, I proposed a range<> class with pop_front, etc. members that adjusted the bounds of the range. Discussion there indicated that committee members were uncomfortable using the same names for lightweight range operations as container operations. Existing practice doesn't agree on a name for this operation, so I've kept the name used by Google's StringPiece.

This proposal did in fact include a clear(), which was unceremoniously struck off the register in a later, isolated, rationale-starved proposal.

Now, one might argue that the functions could therefore have been provided under different names, but that was never proposed, and it's hard to imagine what alternative names would resolve this problem without being simply bad names for the operations.

Since we can assign a new string_view easily enough, including an empty one, the whole problem is solved by simply not bothering to address it.