I think that would be safer. But then it would presumably disallow things like:

    void frob(std::string_view sv);
    std::string a = "a";
    std::string b = "b";
    frob(a + b);

This is allowed today and does not have any problems that I'm aware of. You could work around this by changing the call to:

    frob(std::string_view(a + b));

But that feels cumbersome. I think the goal of std::string_view was to be useful as a parameter for a function so that you could pass in anything remotely string-like and it would implicitly convert and do what you meant. Requiring explicit conversions at the call sites would go against that goal.

Another thing that was desired was the ability to take an existing function that takes a `const std::string&` and change it to instead take a `std::string_view` and not have to update any of the callers. If some callers that worked with the old function are going to need an update to work with the new function then it gets a lot harder to change the function. Or maybe impossible if you don't control all of the callers.

I don't see how you can get both the ease-of-use and the safety short of reinventing something like Rust's lifetimes.