pub struct Handle<T> { /* private fields */ }Expand description
An opaque, copyable reference to a value stored in a Region.
A handle wraps a slotmap::DefaultKey (an index plus a generation) and a
region_id that identifies which Region instance the handle belongs to.
It is Copy and unconditionally Send + Sync regardless of T — it owns
no T, it only names one. The PhantomData<fn() -> T> keeps the handle
typed (so a Handle<A> cannot be passed to a Region<B>) while staying
covariant in T and free of any drop/auto-trait obligations.
The region_id: NonZeroUsize field ensures that handles from different
Region instances never collide even if they have the same key. Using
NonZeroUsize preserves the niche optimization for Option<Handle<T>>.
region_id is pointer-width (not a fixed 64 bits) so this type stays
buildable on no_std targets without 64-bit atomics (e.g.
thumbv7em-none-eabi, i686-*) — every such target
still has pointer-width atomics.
§Layout is an observed property, not a guarantee
This crate does not use #[repr(C)]/#[repr(transparent)] here — there is
no FFI or C-ABI use case for Handle<T>, and one would be misleading
regardless: the inner slotmap::DefaultKey is itself not #[repr(C)]
upstream, so pinning only the outer field order would not yield an actual
stable C layout. size_of::<Handle<T>>() (16 bytes on a 64-bit host, 12 on
32-bit) and the Option<Handle<T>> niche optimization are current,
observed properties of this implementation, verified by
tests/handle_static_asserts.rs — a tripwire against silent drift (e.g. a
future slotmap minor bump changing DefaultKey’s size), not a stable
public contract. If a genuine FFI need arises, the crate would add an
explicit to_raw/from_raw conversion pair rather than promise this
struct’s layout.
Trait Implementations§
impl<T> Copy for Handle<T>
impl<T> Eq for Handle<T>
Source§impl<T> Ord for Handle<T>
impl<T> Ord for Handle<T>
1.21.0 (const: unstable) · Source§fn max(self, other: Self) -> Selfwhere
Self: Sized,
fn max(self, other: Self) -> Selfwhere
Self: Sized,
Source§impl<T> PartialOrd for Handle<T>
Ord/PartialOrd provide a total order consistent with Eq, suitable
for storing Handle<T> in a BTreeMap/BTreeSet or sorting a Vec of
them. The relative order between two particular handles — including
whether handles from different Regions group together
or interleave — is an unspecified implementation detail (currently:
group by region_id, tie-break by key) and may change in any release.
Do not depend on it for anything beyond “a total order exists”.
impl<T> PartialOrd for Handle<T>
Ord/PartialOrd provide a total order consistent with Eq, suitable
for storing Handle<T> in a BTreeMap/BTreeSet or sorting a Vec of
them. The relative order between two particular handles — including
whether handles from different Regions group together
or interleave — is an unspecified implementation detail (currently:
group by region_id, tie-break by key) and may change in any release.
Do not depend on it for anything beyond “a total order exists”.