Perhaps it would be possible to apply some compile-time transformation to 
mitigate the problem:

Transform

void f() {
    .....
    f(); 
}

into

void f() {
   ....
   take ownership
   f1();
   drop ownership
}
void f1() {
   ....
   f1();
}


Marijn Haverbeke 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. These two
> things are at odds, and I'm currently leaning in the direction of
> giving up tail calls.
>
> I'm coming from a functional background and am very aware of the
> awesome elegance of tail calls. However, in actual rust code, they
> seem to be used rarely. I think the reason for this is that, in Rust,
> scope and memory management are very closely intertwined, which
> prevents most elegant recursive patterns from being efficient. If you
> have GC, you can skip in and out of scopes with very little penalty.
> In Rust's memory model, you tend to pay a hefty price in allocation
> and complexity for this jumping, and the loop-based way to write
> something is usually simpler anyway.
>
> This is not to say that tail calls are useless. They work well in a
> few specific situations (simple forwarding functions, recursive things
> that don't build a data structure). What I want to say is that they
> might not be worth the cost, and that we can do some very promising
> things if we lose them. I am also not at a point where I know for sure
> that my sketch of the new aliasing system will be viable. I just want
> to know whether I should feel free to explore this option. Who feels
> strongly that tail calls should be preserved?
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to