On Sun, Jul 31, 2011 at 4:55 PM, Marijn Haverbeke <[email protected]> wrote: > I've been throwing around some ideas about a simpler way to 'alias' > (non-owning reference) things with Patrick, and am in the process of > working out some ideas. A bunch of the possible directions, and the > ones that seem most promising to me at the moment, work poorly with > tail calls. Having the ownership management (take/drop) of parameters > happen entirely on the caller side means that the caller can optimize > them away in some situations. Supporting tail calls means that the > take must happen in the caller, but the drop in the callee.
I want to make sure I understand this. Suppose you have a function f that passes a box (which is reference-counted) to a function g. g now has ownership of the box, so a refcount has to be incremented, then decremented again when g returns. But if you have tail calls, and f made a tail call to g, then the decrement must happen in g, because f's frame might no longer be around. Marijn's point was that we would rather have both the increment and the decrement happen on f's side, because apparently that makes it possible to optimize away the increment/decrement in some situations. What about having both the increment and decrement happen on g's side? Is that possible, and if so, would it do any you any good with respect to optimizability? Lindsey _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
