I'd be curious to see how much CPU time is wasted on looking for a null every time strlen is called. The extra length integer is probably insignificant compared to that.
It is very expensive if you repeatedly measure and forget the length, this is presumably some of the price in Google's problem where some engineers wanted to use 0-terminated char* as the type of a string but others wanted C++ std::string and so the software ends up measuring how long the string is, allocating and copying, then immediately forgetting that length, only to once again measure how long it is, allocate and copy again.
That's a language design defect, C++ got its string slice reference (named std::string_view) only in 2017, years after Rust 1.0 shipped this as a core language feature, even though C++ is decades older.
On the other hand I can well believe on a 1970s computer where you'd be lucky to have 64kB of RAM the trade looks very different, I just think that by C89 it should have been fixed.
The problem with C++ string slices is that after many years of C++ becoming increasingly memory-safe with std::string and smart pointers, now we reverted to something barely more safe than a C string.
I guess Rust can keep slices safe using some borrow checker magic or something, but C++ can't.
It's true that the borrowck is what checks you didn't screw this up in Rust, but "it's your job to never make mistakes" is just how C++ always works
If you keep const pointer to a std::string in C++ in 2016 that's exactly the same danger (of dangling pointers) as for a std::string_view in 2026, there's no change to that part.
