I had a similar problem when writing an iterator for a tree-like data structure. The iterator held a stack (vector) of per-node iterators and needed to push into it while accessing the last node.
In my case the whole thing works with owned and burrowed pointers. I managed to implement the immutable iterator by providing the correct lifetime incantation and, like you said, only using indices (actually I implemented a `mut_last()` function for mutable vectors - somehow this isn't in the standard library - but this is just a shorthand for accessing by `[len() - 1]`). I couldn't get any safe code to work for the mutable iterator though :-( I ended up using an unsafe code with a `*mut` pointer. It seems like you could do the same, if you are willing to give up the type-enforced safety... I love the compiler-enforced safety wrt. pointer lifetime and ownership, but like all type systems it has its limitations. It seems that the current approach is to implement safe containers with very careful sprinkling of `unsafe` (hey, even std::vec does it!), and then to have the bulk of the code use these safe containers. Maybe you could do something similar. It would be awesome if one could come up with a non-zero-cost extension to the type system where one could say "I know this seems unsafe but I assert it is just because the static type system is too weak; please insert minimal efficient dynamic assertions that things are OK". This would need to be explicit since it would incur some (hopefully low) run-time penalty. Probably such a mechanism wouldn't be 100% generic, but if we had a list of cases where people were forced to resort to unsafe code, perhaps we could cover the interesting "80%" of the cases and somehow provide them as a library or macro or something. ARC and RW ARC are sort of like that (libraries compensating for too-weak builtin-types system), maybe we need more? On Tue, Aug 20, 2013 at 7:54 AM, Jeaye <[email protected]> wrote: > Howdy, > > I've become a big fan of @mut throughout my codebase for its compatibility > with closures, but I think it's really biting me in the ass right now. >.< > > Assume there's a state stack (in a state Director) that I'm looping > through to let the states know about an event. In this particular instance, > the event is a key action of ENTER, since 'load_map q3ctf1' was just typed > into the in-game console and ENTER was pressed. The console state is > interested in this event, no doubt. > > When the console state gets this load_map command, it'll spring off a > function that creates a game and game_renderer, which are both states that > need to be pushed onto the state stack. But wait! We're currently looping > through the state stack, so trying to add something to it is an assertion > failure on the borrow (BAM, hard failure). > > In C++, this could would be perfectly valid, so long as I'm iterating > through the state stack with indices and I'm pushing to the end of it, thus > not affecting the current index. In Rust, this is a big no-no. My question > is: how can I avoid this? Is it just because I'm using @mut that I'm having > this problem? What are some potential solutions that people can think of, > and has anyone hit the same snag in their own code? > > Something I have tried: Adding a queue to the state Director of callback > functions (deferred modifications to the states) that states will push > closures onto instead of modifying the Director while it's looping. With > this, the Director could loop through each state, updating it, and then > loop through the queue of deferred callbacks and run them, which would > update the states stack. This didn't work for me since the Director itself > has the borrow lock on it, not just the states stack -- I reckon I could > put the deferred queue into TLS so that I wouldn't need a mutable reference > to the Director to add to it... but there has to be a better way. > > Any tips would be appreciated. > > Jeaye > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
