Support slices in OnceRef and OnceBox

[nvzqz]

This is implemented through a new public-in-private OncePointee trait. If this was instead done with impl OnceRef<[T]>, the compiler fails to infer which methods we want to use.

Because of the usage of core::ptr::slice_from_raw_parts in const, this change increases the MSRV to 1.64.0.

To make correctness easier to reason about, I did not use Ordering::Relaxed. However, it's likely that this code could be improved by it.

[notgull]

I would discourage bumping the MSRV past 1.63, as that is the current MSRV for Debian Stable

[matklad]

Compatibility with Debian stable is an explicit non-goal for once_cell:

#201 (comment)

[nvzqz]

I can rewrite this to use an associated type via OncePointee instead of UnsafeCell<*mut T>. That should remove the need to bump the MSRV.

[matklad]

It’s a fundamental invariant of OnceCell that it doesn’t do unbounded spinning. If mutex-like blocking behavior is needed, then std dependency is required, because correct blocking fundamentally requires talking to the OS and notifying it which other thread you are blocked on, so that the OS can correctly guard against priority inversion.

[nvzqz]

What do you recommend we do here?

[matklad]

My understanding is that no good solutions are available here: either a mutex or a cas is required. Though, I think Rust has double-word cas available on at least some architectures:

https://doc.rust-lang.org/stable/core/arch/x86_64/fn.cmpxchg16b.html

So I think the path forward here is to add support for DSTs via double-word-cas, by adding a bunch of cfgs everywhere. Eg, I'd imagine some 32 processors might have AtomicU64? Though, doing that probably requires a research of what's the status quo for wider-than-word atomic operations in today's Rust. That intrinsic exists, so its non-zero, but I don't know best practicies for actually using that.

[nvzqz]

@notgull I refactored the code to only require bumping to 1.61.0.