Nonnull variant (or high-level variant?)

[simnalamburt]

It seems that the current version, being designed with internal pointers for concurrent data structures in mind, results in Rc, AtomicRc, Weak, and AtomicWeak all being nullable. However, for developers who intend to use them as a smart pointer alternative, it might be better to make them non-nullable by default and provide a separate nullable type when needed. How should the interface be designed to achieve this?

[powergee]

Thank you for your suggestion. We have previously considered implementing AtomicRc to return Option<Rc>s to clients, allowing them to avoid dealing with null cases while also providing a more Rust-friendly API. At that time, we decided to postpone the decision because it seemed that the solution would result in more verbose pointer tagging (similar to Java’s AtomicMarkableReference).

If we are planning to implement a non-null variant for convenience, I think there are two possible approaches:

1. (Simplest) Adding a non-null variant layer on top of AtomicRc and Rc.

   • We can create a wrapper struct (e.g., AtomicRcNonNull) that contains a markable pointer type (e.g., AtomicRc) as an inner value and redirects all method calls to its inner type while using only empty tag bits.
   • This approach is the simplest in terms of implementation, but it may involve unnecessary low-bits checking since the inner type would still assume that the low-bits might be in use.

2. (More Efficient) Creating a dedicated non-null variant by reusing the low-level Tagged primitive.

Between these two options, I personally prefer the second one. If I have the time, I would like to design new API structures to support this approach.