3 ms·
It's long enough ago I can't remember exactly what I was trying to do except that it was trivially correct, but yeah I think that was it. Anyway, I'm glad that'
by smitherfield 9y ago
It's long enough ago I can't remember exactly what I was trying to do except that it was trivially correct, but yeah I think that was it. Anyway, I'm glad that's been solved; looks like I've got some new weekend plans! :)
- vvanders 9y agoAwesome :). Something else to keep in mind that while it's nice to have the borrow-checker validate everything it's okay to step around it if you've got a case that's gnarly and you know is valid. I've had some C callback stuff where I run into that occasionally, I can't encode the lifetime semantics to the calling function so I have to side-step it. In that case things like RefCell(which are separate from (A)Rc/Box) are a great "escape hatch". Obviously you should try and keep it to a minimum but don't let it be a complete roadblock.
- Sharlin 9y agoClosures still borrow whole structs from the captured scope when they could only borrow the fields they actually need: https://play.rust-lang.org/?gist=26b2efa859589a8172cad982f0dfb89b&version=stable https://play.rust-lang.org/?gist=26b2efa859589a8172cad982f0d... This is especially frustrating when it's self that is being captured. There's an accepted RFC for fixing this but I'm not sure when it's going to be implemented.
- vvanders 9y agoYou can work-around that by capturing the fields you need individually. It's a little awkward but does let you express what you're trying to do there: https://play.rust-lang.org/?gist=2463ff559d7f96f916d246272b19ff68&version=stable https://play.rust-lang.org/?gist=2463ff559d7f96f916d246272b1... Agreed that it's not the best default behavior though. Generally I tend to try to keep unrelated things in separate structs for this reason(with the nice side benefit of keeping concerns separate).