this post was submitted on 02 Jun 2024
47 points (100.0% liked)

Rust

5980 readers
95 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 7 points 5 months ago (2 children)

I’m curious how they plan on implementing interior references while keeping structs that contain them movable and without breaking the “moving structs is always just memcpy” assumption.

All of these would be great to have though, would make the language a lot more ergonomic. I hope they get implemented.

[–] [email protected] 6 points 5 months ago

The more I thought about the interior references part the more questions I had! For example:

  • The actual characters in a String belong to a dynamic memory allocation rather than to the String object itself, so the lifetime of &str references into there is "until any operation that might change the size of the allocation". Since that level of detail doesn't seem visible to to the type system even with the discussed addition, I guess it would reduce just to disallowing any mutable reference to the string so that its content cannot possibly move to a new allocation while the internal references are live. 🤔
  • I also thought about the idea that a reference whose lifetime is related to another field in the same object could be represented as an offset from the object's address rather than an absolute pointer and then generate relative accesses when dereferencing, but that would mean that the referents would need to always live inside the object itself, and not in a dynamic allocation as would be the case for &str into a String.

So, with all of that said, I'd love to read an article with more details on that part!

[–] [email protected] 3 points 5 months ago

It's mentioned in footnote 6:

As an example, to make this work I’m assuming some kind of “true deref” trait that indicates that Deref yields a reference that remains valid even as the value being deref’d moves from place to place. We need a trait much like this for other reasons too.

It would only work for references that are stable after the value they reference is moved. Think for example of a &str you get from a String.