6 ms·
As they mentioned in the original post, a big problem is that TCO does not play nice with two other important features they want. 1. deterministic destructors
by ufo 14y ago
As they mentioned in the original post, a big problem is that TCO does not play nice with two other important features they want.
1. deterministic destructors that run at the end of functions (therefore making things that look like tail calls not actually tail calls) and
2. binary compatibility with C and C++ libraries and tools (they say that tail recursion doesn't let you usethe C calling conventions that these tools and libraries expect you to use)
There is no point in allowing tail recursion in restricted contexts if you can't use these restricted functions to do the sort of stuff Rust was actually made to do
- ihnorton 14y ago> binary compatibility with C and C++ libraries and tools >(they say that tail recursion doesn't let you use the C > calling conventions that these tools and libraries expect > you to use) I've read variations of this comment about Rust C++ compatibility a few times, but haven't managed to find a source. Any references you could point me to?
- kibwen 14y agoAFAIK there's no plan to support any sort of C++ interop natively in Rust. However, it should work just fine if your C++ code exposes a C-compatible interface. Servo has to be able to call into SpiderMonkey somehow.
- kragen 14y agoGCC C++ ABIs are unstable enough that cross-platform C++ libraries usually export a C-compatible interface already.
- ihnorton 14y agog++ vs itself, or g++ vs msvc? g++ uses Itanium C++ ABI on at least linux/mac/mingw, and the mangling and vtable layouts seem to be the same (I'm very interested in any information to the contrary - though I realize vtables are only part of the story).
- kragen 14y agoItanic may be an exception, but there have been at least two backwards-incompatible C++ ABI changes in G++ over the years. Casting to superclass in the presence of multiple inheritance and exception handling have been among the changes. Maybe they should change vtables too, I don't know.
- ihnorton 14y agoFigured as much - it would be hard to take any language seriously without C interop. But that's a long way from "C++ binary compatibility." I've heard this several times, so I was hoping it might be true.
- kibwen 14y agoI've just learned that one of the Samsungers working on Rust has tentative plans to implement C++ interop in the same fashion as D. http://www.reddit.com/r/rust/comments/1c3clf/c_ffi/c9codm1 http://www.reddit.com/r/rust/comments/1c3clf/c_ffi/c9codm1 In any case, I'm not sure that any official Rust source has ever tried to claim "C++ binary compatibility". Perhaps this language is a result of people misinterpreting the fact that Rust lays out structs in memory in the same fashion as C and C++.
- ihnorton 14y agoCool, thanks. I had not seen anything official either - just pipe-dreaming that one of those commenters I saw knew something special.
- asb 14y agoApparently sanxiyn is planning on looking to add support at a similar level to D: http://www.reddit.com/r/rust/comments/1c3clf/c_ffi/c9codm1 http://www.reddit.com/r/rust/comments/1c3clf/c_ffi/c9codm1
- derefr 14y ago> 1. deterministic destructors that run at the end of functions (therefore making things that look like tail calls not actually tail calls) and Couldn't owned boxes (~) passed through the jump transfer their ownership to the next frame (so they'll be destructed by whoever finally does return), and everything else just get destructed before the jump?
- pcwalton 14y agoYeah, we discussed the possibility of doing this. But we eventually decided that it wasn't worth it due to these issues: * It's surprising behavior for destructors, which can have side effects. C++/D RAII and try/finally in other languages never behave like this. * You can do it yourself, by moving the values-to-be-destructed into the bit bucket with "let _ = ..."; * You still have the ABI issues in that you can't use cdecl and have to use Pascal/stdcall to get TCO.