4 ms·
I love that structs can be strictly non-copyable. This way I don't need to heap allocate objects to ensure their uniqueness. I can still modify them in place w
by pornel 3y ago
I love that structs can be strictly non-copyable.
This way I don't need to heap allocate objects to ensure their uniqueness. I can still modify them in place without worrying there will be any out-of-date copies that weren't updated. Or I can give out simple ints or even zero-sized structs that can be handles/tokens that grant exclusive or single-use access.
- monocasa 3y agoUnfortunately I haven't been able to find a way to make structs completely noncopyable except via Pin. The compiler is reference tracking, and if it's sure that there aren't references it'll copy the value around. So for instance full RVO isn't guaranteed, and you can catch the bit pattern of &self changing out from under you even in a struct that doesn't implement Copy. I'd kill for a proper copy constructor to cover the edge cases.
- pornel 3y agoYou're expecting a stable address, but that's a different thing. Rust will move structs to a new address if it needs to, but still enforce that there's semantically a single instance (its old address becomes inaccessible).
- nynx 3y agoYou’re complaining that something else is copyable.
- monocasa 3y agoI'm complaining that the object I've built will have literal memcpy(3) called on it.
- John23832 3y agoAt a certain point, the compiler can’t save you and you have to actually know the limitations of the data you’re working with.
- monocasa 3y agoI do know how, as I listed how to in my original comment: using Pin. It's just been very unergonomic in a couple cases because I don't actually care in some of those cases of the struct is copied, I just want know when &self's bit pattern changes and there's no way in rust to know that.