You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
simnalamburt
changed the title
Nonnull variant
Nonnull variant (or high-level variant?)
Oct 8, 2024
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:
(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.
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?
The text was updated successfully, but these errors were encountered: