[saagarjha]

> Eventually C++ gets std::string and std::wstring but, nothing of value about these strings is defined, so they're both pretty useless and of course dangerous. In C++ 17 it gets std::string_view which finally expresses one of the things you probably first wanted

Such as what? std::string_view represents exactly one thing, and that’s a slice into a string with a lifetime longer than it. That’s basically it. There aren’t really and other additional feature to it, so I feel like you may be confused as to what it does.

[tialaramex]

Yes, it's "just" a slice. Which is in fact one of the most obvious things you would want, and yet was not afforded by std::string.

[capitalsigma]

A lot of your criticism makes sense. I don't follow this one, though: `string_view` is *by definition` non-owning. Was non-owning the whole thing you wanted? If so, why are you surprised by lifetime issues? If non-owning isn't your main desire, what's wrong with `std::string`?

[tialaramex]

Probably in C++ context this feels unreasonable but I'm arguing that C++ is wrong here. It's OK for the language to enforce that the lifetime of the string underpinning a slice must equal or exceed the lifetime of the slice despite the slice not "owning" the string.

In 2011 there probably wasn't a mainstream non-GC language doing that. C++ would have been innovating here, and maybe C++ in 2011 didn't want to be innovating. By 2017 when C++ 17 introduces std::string_view it's behind the curve, this is not an exciting new feature, it's a weak imitation of what everybody else was already doing better.