How can I use unsync::OnceCell or unsync::Lazy for a type that is not sync?

I'm looking into once_cell's functionality to lazily initialize a global/static instance. The example in the documentation focuses on the Sync case, i.e., it uses sync::OnceCell / sync::Lazy.

I'm wondering how that would work for a type that is not Sync. Simply translating the sync::Lazy to unsync::Lazy would result in (using this trick to emulate a non-sync type):

use once_cell::unsync::Lazy;

// Example of a type that is not sync
struct TypeNotSync {
    _marker: PhantomData<Cell<()>>,
}

static GLOBAL_DATA: Lazy<TypeNotSync> = Lazy::new(|| 
  // Let's ignore the actual initialization for now...
  unimplemented!()
);

This doesn't compile, and the compiler insists that the underlying type has to be Sync.

error[E0277]: `Cell<std::option::Option<fn() -> TypeNotSync>>` cannot be shared between threads safely
   --> src/resources.rs:75:21
    |
75  | static GLOBAL_DATA: Lazy<TypeNotSync> = Lazy::new(|| unimplemented!());
    |                     ^^^^^^^^^^^^^^^^^ `Cell<std::option::Option<fn() -> TypeNotSync>>` cannot be shared between threads safely
    |
    = help: within `once_cell::unsync::Lazy<TypeNotSync>`, the trait `Sync` is not implemented for `Cell<std::option::Option<fn() -> TypeNotSync>>`
    = note: if you want to do aliasing and mutation between multiple threads, use `std::sync::RwLock`
note: required because it appears within the type `Lazy<TypeNotSync>`
   --> /home/fabian/.cargo/registry/src/index.crates.io-6f17d22bba15001f/once_cell-1.18.0/src/lib.rs:716:16
    |
716 |     pub struct Lazy<T, F = fn() -> T> {
    |                ^^^^
    = note: shared static variables must have a type that implements `Sync`

The same happens when using unsync::OnceCell directly.

I'm a bit confused now. I'd expected the unsync flavors of OnceCell / Lazy should not require my type to be Sync. In fact, looking at the reference docs, unsync::OnceCell itself doesn't seem to require T: Sync. It looks like it is rather imposed by the compiler because of the static, because using a local let not_global_data: Lazy<TypeNotSync> = ... inside a function compiles. However, this defeats the purpose of using OnceCell -- after all, the goal was to get a "lazy static".

So the question becomes: How can OnceCell be used in combination with a non-sync type?

It cannot.

If a type is not Sync, is it not safe to have multiple shared references to it in different threads. OnceCell let you do that, so it is not safe to use in static with non-Sync types, by the definition of Sync.

Take RefCell, for example: if you put it in a static, even behind a OnceCell, you can modify it concurrently from multiple threads and cause a data race. OnceCell does not change that. It only affects the initialization of the type.

If you have a type that is neither Sync nor Send, then you cannot use it in static safely. A possibility (maybe implemented in some crate) is to have a static with it (unsafely) with only one thread allowed to use it, and send commands (and receive back results) to this thread via channels.

If the type is not Sync but is Send, you can use a Mutex. It has the unique property of making non-Sync (but Send) types Sync, because it never yields shared references to them: all it allows is mutable references, not concurrently.

Since !Sync means a type cannot safely be accessed from multiple threads a plain static obviously cannot safely hold such a value since it can be accessed from all threads.
The obvious usecase for a std::cell::OnceCell/once_cell::unsync::OnceCell are thread local statics:

thread_local!{
    static X: OnceCell<TypeNotSync> = OnceCell::new();
}
// use `X` with one instance per thread.

You can use thread_local to create non-sync static values.

thread_local! {
    static GLOBAL_DATA: Lazy<TypeNotSync> = Lazy::new(|| 
        unimplemented!()
    );
}

This is pretty useless, though, since thread_local already lazily initializes the values.

The non-Sync types in once_cell are mostly useful for cases where you do not know if or when a value will be initialized.

fn main() {
    let global_data: Lazy<String> = Lazy::new(||
        "initialization".to_string()
    );

    for _ in 0..4 {
        if rand::random() {
            println!("{}", *global_data);
        } else {
            println!("no initialization");
        }
    }
}

This allows you to separate initialization logic from the rest, which may create clearer code, as well as remove the requirement of mut from initialization.

You can also pass this around opaquely as impl Deref<Target = String> without making Lazy visible in the API. It's also a good type to express an expensive deref.