I understand that tail calls aren't working with the current state of things, and I won't get in the way. Fair warning: I am not promising I won't argue for bringing them back at some point in the future.
> - The alias-optimizing issues discussed earlier in this thread I've been chatting with Patrick, and I still think it's conceivable that we could have an ABI where tail calls are "pay-as-you-go," i.e., where they don't incur a cost on every non-tail-call. As I said before, I think when the time is right, we should investigate whether GC works better than refcounting, at which point I definitely think we should reconsider tail calls. > The changes makes the compiler 5% smaller, and both patches remove > more code than they add, so in terms of complexity, this is a definite > win. Certainly it's a win in terms of development costs, but that doesn't mean it's a savings for the user. JFTR, I don't think we should be making decisions about removing features because of savings in the compiler. > If you have reasons to object to this patch that go beyond "but in > <garbage-collected language of choice> tail calls are very important", > let's hear them. Please don't mock or misconstrue the arguments of others if you aren't going to address them directly. Dave _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
