StaticRc is a safe reference-counted pointer, similar to Rc or Arc, though performing its reference-counting at compile-time rather than run-time, and therefore avoiding most run-time overhead.

Motivating Example

A number of collections, such as linked-lists, binary-trees, or B-Trees are most easily implemented with aliasing pointers.

Traditionally, this requires either unsafe raw pointers, or using Rc or Arc depending on the scenario. A key observation, however, is that in those collections the exact number of aliases is known at compile-time:

• A doubly linked-list has 2 pointers to each node.
• A binary-tree has 3 pointers to each node: one from the parent, and one from each child.
• A B-Tree of cardinality N has N+1 pointers to each node.

In this type of scenario, static-rc offers the safety of Rc and Arc, with the performance of unsafe raw pointers.

Goals

Provide safe and efficient reference-counting:

• Efficiency: most associated functions boil down to copying a NonNull<T>, a trivial operation.
  • One key exception are join functions: a run-time check must be performed to ensure the instances being joined refer to the same pointer. Unsafe unchecked variants are available if their overhead is too high.
• Safety: most associated functions are safe to use.

  • The few unsafe functions are strictly optional.

Maturity

This crate is still very much experimental.

Review:

• Minimally reviewed.
• Not audited.
• Not formally proven.

Documentation:

• All StaticRc associated functions are documented, with example.
• All StaticRcRef associated functions are documented, with example.

Testing:

• All compile-time assertions are tested with compile-fail tests.

• All panics are tested with panic tests.

• Miri runs the test-suite without any complain.

Debug checks

This library contains a number of additional checks when building with debug_assertions, in particular the Drop implementation of StaticRc will catch any attempt at destroying a StaticRc<T, N, D> where N <> D, as this would typically result in a leak.

Those checks are not strictly necessary for safety, they are included to help point out logic errors.

From experience, the Drop check on top of an extensive test-suite will help catch all those instances where one path accidentally let a pointer drop.

That's all folks!

And thanks for reading.