On 11-08-10 07:16 PM, Jesse Ruderman wrote:
The point of having a "be" keyword, in my mind, is to give programmers a way to tell the compiler "let me know if I'm doing anything that prevents this call from being optimized". Seen that way, it's essentially a static assertion. The offense against compositionality didn't come from the "be" keyword; it came from the inability to optimize the call, which exists with or without the "be" keyword.
The conflict is how hard we try to work to make sure compositionality reigns, and we get to use 'be' everywhere, or "enough to be useful". If we don't try very hard at all, we can possibly ship it, but it'll only be usable in a handful of cases.
I mean, at the limit merely "having all callees be tail-callable" -- those where it's even *possible* in the runtime model -- is itself a performance hit and C-ABI-compatibility break due to the callee-pops nature of the arg passing. This is possible but it's a penalty. One we're currently paying and .. might like to stop, if we can.
The error messages can make sense, right? I admit to not understanding most of the cases.
They can make sense, yes. Just a question of extent, cost, tradeoff. -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
