I read that more as a valid criticism of other parts of C++ rather than about smart pointers as a way to track ownership.
e.g. std::string_view seems broken by design in wanting to support both raw-pointer based strings with zero ownership semantics as well as std::string. A string view (abstract concept) really needs to either have shared ownership of the underlying string, or have a non-owning reference that knows when it has been invalidated.
Well the string view type you wish existed seems to be exactly what Rust gives you, no? Non-owning references that "know when they have been invalidated" (or rather, the compiler prevents you from using them after they have been invalidated).
I'm not sure why this means you shouldn't be able to create a string_view on top of std::string, though. You can create a Rust &str on top of String, it just doesn't participate in ownership.
My comment was just a reply to the parent - that the linked article wasn't really about smart pointers. I was just using string_view as an example.
There are lot's of places where C++'s long history shows it's ragged edges - where newer features really don't play so nice with older ones. One would certainly hope that a new language like Rust is at least initially more consistent.. the question is what will it look like in 20 years time, if it's still being actively developed at that time?
Rust's &str is basically identical to C++'s string_view, for what it's worth. I still don't understand your point about how string_view is inconsistent. The only reason &str is so much easier to use than string_view is because Rust supports borrow checking, making it safe to use, whereas C++ does not.
What I meant about "inconsistency" is that there are std::string_view constructors that accept raw pointers to indicate the range, and others that accept iterators. It's a mix of old (C) & new (C++) data structures, with neither indicating the ownership or longevity of the underlying object.
This is somewhat typical of where C++ is at nowadays - layering new functionality on top of old that wasn't designed to accommodate it. In an ideal world the language and libraries would be refactored and rationalized, but of course backwards compatibility precludes that. This is the fate of old languages - stay unchanged and become obsolete, or keep layering on new functionality and become messy and inconsistent.
e.g. std::string_view seems broken by design in wanting to support both raw-pointer based strings with zero ownership semantics as well as std::string. A string view (abstract concept) really needs to either have shared ownership of the underlying string, or have a non-owning reference that knows when it has been invalidated.