Using string_view before actually requiring C++17 results in either a ton of additional ifdef (which mptString.h and mptString.cpp already have plenty enough of anyway), or another zoo of additional string types named mpt::ustring_maybe_view for each and every string type that we have and still then result in strange const string_view & parameters (or again another set of ifdef). I would rather delay that until we require C++17.

Using value parameters instead of const & for trivial iniline conversion functions pessimizes binary size for me: 4.447.744 bytes (before), 4.453.376 bytes (after) (VS2019 Win32 ReleaseShared).

Let's wait for C++17 then.

C++17 support is now required. We could try using string_viewagain.

mpt::String::ReadBuf() returns a StringModeBufRefImpl object, which currently is implicitly convertible to std::string. Changing mpt::ToUnicode() to take a std::string_view argument breaks implicit conversion (because 2 consecutive conversions would be required). Changing StringModeBufRefImpl to also be implicitly convertible to std::string_view is impossible because of the spacePadded and spacePaddedNull cases which need to modify the actual string data, for which no buffer space would be available unless an actual std::string exists somewhere.

The only way to fix this without breaking implicit conversions for this case would be to add std::string_view overloads in addition to the already existing std::string overloads instead of replacing them, for all mpt::ToUnicode(), mpt::ToCharset(), ... functions. This in turn would break implicit conversion of const char*arguments, which would require another set of overloads. mptString.h is already complicated and convoluted enough even without triple the overloads.