pub unsafe fn fast_new() -> Self {
        // Must increment by 2 to ensure we never overlap with a
        // real pointer.
        // Use `Relaxed` ordering because we don't care
        // who gets which ID, just that they are different.
        let id = FAST_QCELLOWNER_ID.fetch_add(2, Ordering::Relaxed);
        Self {
            #[cfg(feature = "alloc")]
            _handle: None,
            id,
        }
    }
/// Create an owner that can be used for creating many `QCell`
/// instances.  It will have a unique(-ish) ID associated with it
/// to detect using the wrong owner to access a cell at runtime,
/// which is a programming error.
///
/// # Safety
///
/// This call is much faster than [`new()`](#method.new) because
/// it uses a simple atomic increment to get a new ID, but it
/// could be used maliciously to obtain unsafe behaviour, so the
/// call is marked as `unsafe`.
///
/// If used non-maliciously the chance of getting unsafe behaviour
/// in practice is zero -- not just close to zero but actually
/// zero.  To get unsafe behaviour, you'd have to accidentally
/// create exactly `usize::MAX / 2` more owners to get a duplicate
/// ID and you'd also have to have a bug in your code where you
/// try to use the wrong owner to access a cell (which should
/// normally be rejected with a panic).  Already this is
/// vanishingly improbable, but then if that happened by accident
/// on one run but not on another, your code would still panic and
/// you would fix your bug.  So once that bug in your code is
/// fixed, the risk is zero.  No amount of fuzz-testing could ever
/// cause unsafe behaviour once that bug is fixed.  So whilst
/// strictly-speaking this call is unsafe, in practice there is no
/// risk unless you really try hard to exploit it.
Create an owner that can be used for creating many `QCell`
instances.  It will have a unique(-ish) ID associated with it
to detect using the wrong owner to access a cell at runtime,
which is a programming error.
Create an owner that can be used for creating many ` QCell ` instances . It will have a unique ( - ish ) ID associated with it to detect using the wrong owner to access a cell at runtime which is a programming error .
pub unsafe fn fast_new() -> Self {
        // Must increment by 2 to ensure we never overlap with a
        // real pointer.
        // Use `Relaxed` ordering because we don't care
        // who gets which ID, just that they are different.
        let id = FAST_QCELLOWNER_ID.fetch_add(2, Ordering::Relaxed);
        Self {
            #[cfg(feature = "alloc")]
            _handle: None,
            id,
        }
    }
pub unsafe fn fast_new ( ) -> Self { // Must increment by 2 to ensure we never overlap with a // real pointer. // Use `Relaxed` ordering because we don't care // who gets which ID, just that they are different. let id = FAST_QCELLOWNER_ID . fetch_add ( 2 , Ordering :: Relaxed ) ; Self { # [ cfg ( feature " " ) ] _handle : None , id , } }
Create an owner that can be used for creating many `QCell`
instances.
Create an owner that can be used for creating many ` QCell ` instances .
safety
This call is much faster than [`new()`](#method.new) because
it uses a simple atomic increment to get a new ID, but it
could be used maliciously to obtain unsafe behaviour, so the
call is marked as `unsafe`.

If used non-maliciously the chance of getting unsafe behaviour
in practice is zero -- not just close to zero but actually
zero.  To get unsafe behaviour, you'd have to accidentally
create exactly `usize::MAX / 2` more owners to get a duplicate
ID and you'd also have to have a bug in your code where you
try to use the wrong owner to access a cell (which should
normally be rejected with a panic).  Already this is
vanishingly improbable, but then if that happened by accident
on one run but not on another, your code would still panic and
you would fix your bug.  So once that bug in your code is
fixed, the risk is zero.  No amount of fuzz-testing could ever
cause unsafe behaviour once that bug is fixed.  So whilst
strictly-speaking this call is unsafe, in practice there is no
risk unless you really try hard to exploit it.
This call is much faster than [ ` new () ` ] ( #method . new ) because it uses a simple atomic increment to get a new ID but it could be used maliciously to obtain unsafe behaviour so the call is marked as ` unsafe ` . If used non - maliciously the chance of getting unsafe behaviour in practice is zero -- not just close to zero but actually zero . To get unsafe behaviour you ' d have to accidentally create exactly ` usize :: MAX / 2 ` more owners to get a duplicate ID and you ' d also have to have a bug in your code where you try to use the wrong owner to access a cell ( which should normally be rejected with a panic ) . Already this is vanishingly improbable but then if that happened by accident on one run but not on another your code would still panic and you would fix your bug . So once that bug in your code is fixed the risk is zero . No amount of fuzz - testing could ever cause unsafe behaviour once that bug is fixed . So whilst strictly - speaking this call is unsafe in practice there is no risk unless you really try hard to exploit it .