| ▲ | Animats 3 hours ago | |
The problem in Rust is that if B is inside of A,
you can't have a writeable reference to both A and B at the same time.
This is alien to the way C/C++ programmers think. Yes, there are ways around it,
but you spend a lot of time in Rust getting the ownership plumbing right to make this work. | ||
| ▲ | anon291 25 minutes ago | parent | next [-] | |
It's kind of crazy that OOO is sold to people as 'thinking about the world as objects' and then people expect to have an object, randomly take out a part, do whatever they want with it and just stick it back in and voila This is honestly such an insane take when you think about what the physical analogue would be (which again, is how OOP is sold). The proper thing here is that, if A is the thing, then you really only have an A and your reference into B is just that, And should be represented as such, with appropriate syntactic sugar. In Haskell, you would keep around A and use a lens into B and both get passed around separately. The semantic meaning is different. | ||
| ▲ | vlovich123 2 hours ago | parent | prev [-] | |
> you can't have a writeable reference to both A and B at the same time > but you spend a lot of time in Rust getting the ownership plumbing right to I think you maybe meant to say something different because here's the most obvious thing:
Now it may take you a while to figure out if you've never done Rust before, but this is trivial.Did you perhaps mean simultaneous partial field borrows where you have two separate functions that return the name fields mutably and you want to use the references returned by those functions separately simultaneously? That's hopefully going to be solved at some point, but in practice I've only seen the problem rarely so you may be overstating the true difficulty of this problem in practice. Also, even in a more complicated example you could use RefCell to ensure that you really are grabbing the references safely at runtime while side-stepping the compile time borrow checking rules. | ||