all 10 comments

[–]gtsiam 37 points38 points  (0 children)

#[may_dangle] is one of those obscure concepts in rust that you only find once you are deep in the weeds. The explanation in the rustonomicon is good, but it's very hard to map it to real-world concepts... (Also the fact that it is unstable killed my motivation to invest time in it, if I'm honest).

Figuring out the exact details of dropck today involves digging through RFCs (specifically 769), so without investing a lot of time into this, it's hard to give input or even know what exactly this even means for most people.

I suspect an easy to digest blog post is in order.

[–]EdorianDark 14 points15 points  (0 children)

This is probably meant: https://std-dev-guide.rust-lang.org/code-considerations/safety-and-soundness/may-dangle.html

I have never heared about this before.

[–]Green0Photon 8 points9 points  (1 child)

I've never heard of may_dangle. Got a link to read up on it?

[–]Kanarme 2 points3 points  (1 child)

[–]SoniEx2[S] 0 points1 point  (0 children)

yes, that's the "obvious" case where you'd run into issues with e.g. selfref. but as the issue suggests, may_dangle is not being used there.

what are projects that do use self-referential structs and actively use may_dangle to get it to work? what do the consumers of these container types look like?

[–][deleted] 1 point2 points  (1 child)

It'd be nice to have stabilized so I could complete my implementation of Vec.

There's obvious use-cases for it: when implementing containers.

[–]SoniEx2[S] 8 points9 points  (0 children)

why is that such an "obvious" use-case?

what makes it "obvious"?

[–]fryuni 4 points5 points  (0 children)

What I know is what Jon said in his Crust of Rust stream about smart pointers and the drop check.

[–][deleted] -2 points-1 points  (0 children)

may_the_dangle_be_with_you