> So I think that after the lengthy discussion here, this issue can now be closed. In summary: the use-after-free potential with string_view is accounted for in the Lifetime profile, even if there may be bugs or limitations in preliminary implementations that mean it is not diagnosed.
This is the big difference across both language communities, being willing to improve instead of being stuck with what was born alongside UNIX.
C++ is certainly a better boat to be in thanks to RAII and other things, but static analysis is not a panacea here.
> even if there may be bugs or limitations in preliminary implementations that mean it is not diagnosed.
The huge assumption there is that finding all or even most lifetime bugs involving string_view and other dangerous C++ idioms via static analysis is tractable, that it's just a matter of "overcoming bugs in preliminary implementations of the analyzer". There is no reason to believe that; in fact there are good reasons to disbelieve that, including:
* Languages with static lifetime checking, i.e. Rust, found it necessary to add lifetime annotations, which the C++ lifetime guidelines don't have.
* Just after that Github discussion, Herb Sutter released version 1.0 of the C++ Lifetime Guidelines with dramatically scaled-down ambitions. See https://robert.ocallahan.org/2018/09/more-realistic-goals-fo.... Anyone relying on the unrealistic promises of version 0.9, probably including the commenters in that Github discussion, would have had their hopes dashed.
Relying on the emergence of some crazy-powerful static analysis to save us reminds me of the Itanium fiasco, where poor performance was portrayed as a temporary problem while we wait for compilers to "catch up", which of course they never did.
No one is going to port DriverKit, Project Treble drivers, Metal Shaders, WinUI, Windows Universal drivers, ARM mbed, Arduino, AUTOSAR security certification, Qt/KDE, Unreal, PS4/5, Xbox XDK, CUDA, LLVM, DirectX, C++/CLI, C++/WinRT, SYSCL, C++AMP, and plenty of other C++ based tooling to Rust.
At very least, not in the next couple of decades. Keep in mind that it took 30 years for C++ to get where it is, and there are still domains it keeps failing to take away from C.
So having C++ lifetime annotations is better than nothing, in what concerns improving the language's security.
> So I think that after the lengthy discussion here, this issue can now be closed. In summary: the use-after-free potential with string_view is accounted for in the Lifetime profile, even if there may be bugs or limitations in preliminary implementations that mean it is not diagnosed.
This is the big difference across both language communities, being willing to improve instead of being stuck with what was born alongside UNIX.