Not to detract from your general point, but are you sure your example corrupts memory? AsciiStrToUpper returns a std::string (it has to), which in your example becomes a temporary object. Temporaries are destructed at the end of the containing full-expression, which in this case is the whole assignment expression. So StripAsciiWhitespace returns a view into a still-living temporary, and foo2's constructor allocates memory and makes a copy. Only then is the temporary deallocated.
Now, if you wrote absl::string_view foo2 = etc., you'd have a dangling view for sure. In practical industrial usage, you'd build with an address sanitizer (it's built into clang: -fsanitize=address), which should catch that issue.
I missed one important little piece in my example, should be `auto foo2` (to make it more of a landmine) or `string_view foo2` and not `string foo2`, as you've noticed. There's an overloaded func taking string_view and returning string_view.
We use an address sanitizer in tests but not in production. IIRC we had one untested log output line like this that caused corruption in prod.
Now, if you wrote absl::string_view foo2 = etc., you'd have a dangling view for sure. In practical industrial usage, you'd build with an address sanitizer (it's built into clang: -fsanitize=address), which should catch that issue.