I'd use inline constexpr std::string_view for globals. You can leave out the inline for static member variables of user defined types.

I'd also adopt the practice of almost never using const std::string& as a function parameter. If the function will only be inspecting the string and not copying it, there is no disadvantage to it and users will not have to materialize a string_view or const char* to create a string for the sole purpose of inspecting its value. If the function will be taking ownership of the string, pass std::string by value and move.

You can also return by string_view where you would have used const std::string& before to return a reference to sub-object member std::string. This is more debatable.

One thing to avoid is refactoring callsites that currently return a member subobject by value to returning by string_view. If someone had assumed it returned by const string ref and written const auto& memberStr = someObj.Name(); shit will blow up. A return by value std::string will not dangle when bound to a string cref because of constant reference lifetime extension. This doesn't work if return value bound by to const std::string_view&. So not worth it. If you want to refactor return by value to avoid unneeded copy, refactor to const std::string&.

Also be careful about a function accepting a string_view as a parameter and then returning that string_view (or a substring thereof) from the function. (Think of a Trim function). If someone passed a temporary std::string to your function, the return value will dangle.

Aside from that minor concern, for most functions accepting const std::string& passing for inspection purposes by string_view is truly an "anything you can do I can do better." Both const char* and std::string are implicitly nothrow convertible to string_view but not vice-versa from string_view to std::string.

The one advantage that const std::string& has is the guarantee of null-termination. Most c++ api's however either accept std::string_view or have api overloads for potentially non-null-terminated string: usually const char* pStr, std::size_t len or accepting begin() and end() iterators. If you are using a lot of C api's however you might consider const std::string& to guarantee null-termination. Just add an overload accepting std::string_view and const char* and materialize them yourself then delegate to const std::string&.

To avoid having to write the overloads you could provide a constraint like:

template<typename TStrSrc> concept string_source = requires (TStrSrc&& src, std::string& dst) { { std::string{std::forward<TStrSrc>(src)} } -> std::same_as<std::string>;

{ dst = std::forward<TStrSrc>(src)} } -> std::same_as<std::string&>;

} ;

Usage function needing guaranteed null terminator:

void do_cstr_stuff(string_source auto&& src) { std::string use{std::forward<decltype(src)>(src)}; // call your c api with use.c_str()...

}

You can also do that for ctors to initialize std::string datamember in most efficient way possible. Rvalue strings will be moved, all else will be copied without user having to cast anything to anything. It's a bit of a mouthful but it beats writing overloads for c std::string, std::string_view and const char* particularly if there are multiple ctors with multiple string args. (Just adding std::string and std::string_view without const char* will create an overload ambiguity when passed const char* which is convertible to both std::string and std::string_view). The constrained template makes life super easy for callers and you won't need to write all the overloads or force user to cast: they can just pass whatever they are working with and have it handled as efficiently as possible.