Proposal: One more way to make self referial structs.

[tema3210]

Proposal

My idea constists of making a kind of special trait OnCopy, which should have a method to update a value of &this pointer, in order to allow struct refer to itself, outer code shouldn't change it, method should be called only by runtime.As addition in such case we would like to have ability to know is this hook created or not(for compiler needs, program logic).
Usage of the trait should be marked explictly #[Derive(OnCopy)].

UPD: I meant to have no need to overload it, it just may be called to update self-refs in struct, in time of process of move, e.g should be not overloaded. And implemented automatically

UPD 2: Another variant of the proposed trait is building two derive macroses instead of one. One named like #[Derive(SelfRefBase)], and tells compiler that this struct can have self-ref's(Just marker for adding blanket impl. ). Second named like #[Derive(SelfRef)], should mark field that refers to object in struct, require it to be a ref.(via adding it during compile time into static byte array(which indicates which refs in struct should be updated, in order to point to right location))

I've seen the #2613, main difference of these proposals is that there this trait should be marked explictly by user, and not be implemented by one.

[Ixrec]

This feature is generally called "move constructors" after the similar feature in C++11.

The biggest problem with any variation on a move constructors proposal is that it abandons the guarantee that moving a Copy type really means memcopy/bitwise copy without any arbitrary user-defined code. In particular, removing that guarantee now would be a breaking change, since unsafe code can currently rely on things like "moves can't panic".

The second biggest problem is that move constructors don't actually solve the self-referential struct problem anyway. They obviously help in some simple cases, but to make a fully general and sound solution you need some other language feature like "generative existential lifetimes" (unfortunately I don't think anyone ever wrote out a proper explanation of what this is), which would probably make move constructors superfluous.

https://internals.rust-lang.org/t/idea-limited-custom-move-semantics-through-explicitly-specified-relocations/6704 is one past thread discussing these kinds of ideas.

[eaglgenes101]

For the first issue, I've floated around the idea of a Relocate trait which permits the explicit moving of a !Unpin value behind a Pin. Reception was rather cold when I presented it, so I wouldn't count on getting much support, especially since it doesn't have a reply to other common concerns.

[F001]

Similar ideas had been discussed many times: #2613

[jonas-schievink]

Closing in favor of the existing discussions. It is unlikely that Rust will get something like this.