Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nonnull variant (or high-level variant?) #9

Open
simnalamburt opened this issue Oct 8, 2024 · 1 comment
Open

Nonnull variant (or high-level variant?) #9

simnalamburt opened this issue Oct 8, 2024 · 1 comment

Comments

@simnalamburt
Copy link
Contributor

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?

@simnalamburt simnalamburt changed the title Nonnull variant Nonnull variant (or high-level variant?) Oct 8, 2024
@powergee
Copy link
Member

powergee commented 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:

  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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants