[wizzwizz4]

If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers".

Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48).

Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).

[Galanwe]

> If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe

I have a hard time seeing how you could use self references without a combination of raw pointers, pins/projects, and unsafe code. The tediousness of doing so is pretty much a no-go for any sane developer.

The only sane solution seems to be a generous sprinkle of Arcs, which is _not_ okay in high performance scenarios.

> Per-struct allocators are a work in progress

Yes, and most of us don't really want to use nightly in production. It's been years of work on the allocator work group already, and there's probably still years to wait before a stable release.

> Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads

Well I mean overall any way to allow a somewhat eased setup for storing and retrieving objects to/from shared memory, across processes that do not map said memory at the same location. This is very very annoying to implement in Rust at the moment.

Don't get me wrong though, I think Rust has a lot to offer. But when you dive in even slightly technical subjects in Rust, it soon becomes obvious that the power of C/C++ is far from "just type unsafe" away.

[wizzwizz4]

> I have a hard time seeing how you could use self references without a combination of raw pointers, pins/projects, and unsafe code. The tediousness of doing so is pretty much a no-go for any sane developer.

You just do it. I can't recall a good example at the moment, so I've just thrown together a load of Cells: the thing I was doing when I learnt this technique didn't have any Cells in it.

https://play.rust-lang.org/?version=nightly&edition=2021&gis...

  #[derive(Debug)]
  struct SlotMachine<'a> {
    slots: Vec<Cell<i32>>,
    current: Cell<Option<&'a Cell<i32>>>,
  }

  fn main() {
    let machine = SlotMachine {
        slots: vec![Cell::new(0); 5],
        current: Cell::new(None),
    };
    machine.current.set(Some(&machine.slots[4]));
    machine.slots[4].set(12);
    println!("{:#?}", machine);
  }

> Yes, and most of us don't really want to use nightly in production.

Strictly speaking, this is only needed if you want to use Rust's standard library types with custom allocators. You've been able to have per-struct allocators for your own types since long before I learnt the language.

> Well I mean overall any way to allow a somewhat eased setup for storing and retrieving objects to/from shared memory, across processes that do not map said memory at the same location.

Can't you just store offsets into the memory region, and PhantomData references, then unsafely index the mmap'd region when you need an actual reference? Seems like the same thing you'd do in C, except the function you abstract that with can be a method instead. (Unless I'm still misunderstanding.)