> Note that our use case is in a single-threaded context. Hence, the word safe should not be interpreted as ‘thread-safe.’ Single-threadedness greatly simplifies the design; we need not reason about race conditions such as one where an object is simultaneously moved and accessed on different threads. Extending the design to a thread-safe one is left as an exercise to the reader.
Why intentionally design a worse alternative to std::weak_ptr which has been around since C++11??
> Note that our use case is in a single-threaded context. Hence, the word safe should not be interpreted as ‘thread-safe.’ Single-threadedness greatly simplifies the design; we need not reason about race conditions such as one where an object is simultaneously moved and accessed on different threads. Extending the design to a thread-safe one is left as an exercise to the reader.
Why intentionally design a worse alternative to std::weak_ptr which has been around since C++11??
> Extending the design to a thread-safe one is left as an exercise to the reader.
Doesn't get much glibber than that!