If you are waiting for a Rust-like feature that guarantees memory safety - this won't happen. Changes to the language required for this would break too much. Also, existing code wouldn't compile anymore because it contains a ton of memory bugs.
P2530 isn't really about safety, it's an example of how inadequate package management tooling results in the C++ standard library having to (very poorly) attempt the role of curator instead. C++ needs reclamation mechanisms and astoundingly even in 2023 that still means they need to live in the standard library and be designed by WG21. It's a story about institutional failure.
This is one of a pair of proposals (the other is for RCU) - both of which will likely get accepted - with useful but simplified reclamation schemes. In Rust their equivalents live on crates.io, e.g. https://crates.io/crates/haphazard is more or less the same Hazard Pointers, even based on the same work at Folly - and so they can be updated, or obsoleted, or alternatives may become prominent, it all Just Works™.
Closer to safety work is the proposal to have C++ admit that it's possible for a program to be wrong and yet not throw its hands in the air and refuse to explain what it does, as "Erroneous Behaviour". The idea is that e.g. suppose I declare there's going to be a variable named foo, which is an integer, but then I never actually initialize it. Well that's not OK, that program is nonsense, but C++ has long allowed it, even though it's nonsense, so just refusing to compile would annoy programmers. On the other hand, if foo is now silently zero, we actually introduced new semantics to the language, which isn't OK. With "Erroneous Behaviour" C++ could emit a warning ("Don't do that, uninitialized variable foo") but also zero it anyway. A new syntax would be added to mean "I genuinely don't want this initialized, for some good reason" because it's still C++ so being needlessly dangerous is part of their whole ethos, but at least you did it on purpose.
I tried to find this proposal but the links don't work, once upon a time it was 2795 "Erroneous Behaviour". Maybe the author asked that it be withdrawn for some reason?
I fail to see the difference. You can find hazard pointers and RCU as libraries in C++. The only reason these are proposed for standardization as opposed to other features is that someone is willing to go through the pains for their pet feature.
Actually the rationale document says that "The plan was always to include a basic interface into C++ IS". I'm not sure that "This was always the plan" constitutes a rationale, because it begs the question, but not my circus, not my monkeys.
I'm arguing that C++ has to pay this cost because of inadequate tooling. There is, as you correctly observe, no functional advantage. Unlike std::string_view this is not a situation where shared vocabulary is valuable. I probably do not want to expose my use of Hazard Pointers in an API for third parties, for example.
Look at the story of Hive. It's a niche data container type, it's not necessary vocabulary, it's not a huge performance win for most people, it's not a fundamentally novel core type, in Rust the RFC would have been closed years ago. Aria even tried to banish LinkedList -- she failed, but that's how high the bar was for weird container types. WG21 are still spending committee time on Hive.
If you read the list of authors of the paper it is the who's-who of lock free programming. Many of them designed the c++ concurrent memory model, std::thread, std::atomic. Of course Paul "RCU" Mckenny sees adding RCU to the standard as concluding his work.
Yeah, hazard pointers address one of the very common sources of memory safety problems (iterator invalidation). It's definitely not a magic solution that solves all problems, especially given that none of the standard library containers will use them, but they're a very useful tool.
Hazard pointers matter if you are writing lock-free concurrent data structures and you need a way to handle deferred reclamation after a node delete. It is a very exotic problem to have and it is hardly a 'very common source of memory safety issue'. I'm not sure what they have to do the general iterator invalidator problem.
Well, you could read the proposal? Using them in iterators is one of the use cases it specifically calls out. Hazard pointers are a key part of how Folly's ConcurrentHashMap lets you mutate the hash map without invalidating existing iterators into it, and while that's intended for multi-threaded cases it also works if the writes happen to be on the same thread as the read.
Maybe next year ..