Proper tail call support

[dpw]

Will webassembly support proper tail calls? There is currently a link in https://github.com/WebAssembly/design/blob/master/AstSemantics.md#control-flow-structures mentioning a "signature-restricted proper tail call feature", suggesting such support has been considered, but the link refers to a missing anchor on the post MVP features page: https://github.com/WebAssembly/design/blob/master/PostMVP.md#signature-restricted-proper-tail-calls

If the answer is "maybe", what's the best way to contribute to help such support along?

[jfbastien]

Yes, proper tail calls will be supported, but likely not in MVP. This will be especially useful for functional languages which rely on guaranteed tail-call optimization. See discussions in #33 and #44. How it's supported is still up in the air as it needs experimentation and performance measurements.

[dpw]

I've looked at #33 and #44, and #45 seems related too. But I am sceptical that proper tail call is can be achieved though any mechanism based on control flow analysis (whether irreducible flow control is supported or not).

As you say, functional languages rely on guaranteed tail-call optimizations, though such terminology is frowned upon because it invites confusion with the kind of TCO performed by C/C++/etc compilers, where various restrictions may be imposed on which calls are eligible. So the term "proper tail calls" is used instead. In a language with proper tail calls, any call in a tail position is required to relinquish the storage occupied by the calling activation frame. That includes indirect calls, hence the difficulty for local control flow analysis. So functional language compilers/runtimes usually have explicit tail call operations and calling conventions to support them.

It's great that you are open to the idea of proper tail call support, and I can understand that this issue is out of scope for the MVP. But rather than just closing it, could it be left open but given a post-MVP / post-whatever / icebox label, so that it is clear that the matter is not settled yet?

[jfbastien]

Oops sorry, I didn't mean to close before fixing the documentation. I opened #190 to address this issue (and close this issue). We've been moving issues to the design's text, since it makes it easier for new readers to understand the state of things as opposed to reading the entire state of filed issues.