[steveklabnik]

This is a pain point, but it’s not due to slices; it’s the “self-referential struct problem.” There are various solutions, as you note, but it can be annoying, it’s true. It’s a tough one; in the general case, it’s saving you from problems, but when you know you’re not going to hit those edge cases, it’s less than ideal.

[wtetzner]

Is there a theoretical reason for the "self-referential struct problem", or is it just an artifact of the current borrow-checker implementation?

It doesn't seem unsafe to have a struct field refer to another member of that struct, but maybe I'm missing something.

[steveklabnik]

It's not theoretical, it's practical. Here's some code with a self-referential struct:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Here, we have a self-referential struct. If you run this, you may get different numbers than me, but

  [src/main.rs:17] &f = Foo {
      x: 5,
      p: 0x00007ffcbbba41c0
  }

Here, p points to x. It's all good. The address of f is

  [src/main.rs:19] &f as *const Foo = 0x00007ffcbbba41b8

We move f into oh_no. Its address changes:

  [src/main.rs:25] &f as *const Foo = 0x00007ffcbbba3f28

... but p does not:

  [src/main.rs:26] &f = Foo {
      x: 5,
      p: 0x00007ffcbbba41c0
  }

Any access of p is now a use-after-free.

Does that make sense?

[wtetzner]

OK, so the issue is that references aren't updated when a move occurs. That does make sense.

So to make this work, references would need to be re-written when a move/copy occurs.

I can still see having an easy way to construct self-referential structs being a useful thing, even if the compiler prevents you from moving them. Maybe with a smart clone() method that can update references correctly.

However, I am a little confused about this specific example. I don't understand why oh_no() taking ownership causes f to be copied to a new location. Shouldn't it remain in the same place on the stack? I feel like I'm missing something.

[steveklabnik]

> So to make this work, references would need to be re-written when a move/copy occurs.

Yes! C++ has a concept called "move constructors" that allows for this (this would be that "smart clone" you talk about later in the comment), but we made a decision to not include it. This introduces some nice properties, at the cost of disallowing self-referencing structs.

> I can still see having an easy way to construct self-referential structs being a useful thing, even if the compiler prevents you from moving them.

So, in some sense, this is what the new Pin stuff is about. It lets you say "from this point on, this thing isn't going to move again" and therefore be self-referential.

> I don't understand why oh_no() taking ownership causes f to be copied to a new location.

"Taking owernship" means "move". "move" means "a memcpy from the old to the new location." Rust isn't really special from any other sort of language with value semantics here, other than disallowing you to use the old value, since it was moved out from. Does that make sense?

[wtetzner]

So, in regards to why it's generally not safe to move a self-referential struct, I understand now. My confusion about the memcpy is a tangent ;)

I guess my confusion is that I while realized "move" could mean a memcpy, I didn't realize it always meant a memcpy.

In other words, I thought the compiler would be smart enough to realized the memcpy is unnecessary, even though ownership has been transferred as far as the type system/borrow checker is concerned.

As another example, if you have this situation:

    let x = 45;
    dbg!(x);
    let y = x;
    dbg!(y);

Is there really any reason to allocate separate memory for y, if x is in accessible after y is defined?

Or is this just an implementation detail, and could possibly change in the future?

Also, thanks for being so responsive! I suppose this isn't really the best place to have this discussion ;)

[EDIT] I realize that's not a good example, because 45 will just be copied. But you get what I was trying to show.

[steveklabnik]

Semantically, it’s always a memcpy. In practice, the copy can be elided depending on circumstance. But that’s an optimization, not the semantic.

(And yeah, Copy types are like that too; the only semantic difference between Copy and move is if you can use the old binding.)

Any time! And yeah, the rust forums are probably better but it’s no big deal :)

[SamReidHughes]

I didn't say it was specific to slices. The inconvenience around array slices is because they have a pointer. The non-pointery aspects of Rust slices are an advantage over C++. (E.g. not having pointer arithmetic.)

[steveklabnik]

The thread started out by saying slicing, specifically.

Regardless, no worries, I was just trying to add clarity around details, just in case.