News for hackers. Stuff that matters.
Re:Zero-cost futures in Rust by yazaddaruvala on Thursday August 11, 2016 @03:52PM (#12271118)
I believe he meant, lots of closures. Which is not normal in C or C++, but is the normal in Rust because they are Zero-Cost.

Without knowing anything about LLVM's internals, I would assume it doesn't anticipate so much closure chaining, and therefore doesn't leverage the fact that they are so easy to inline.

Re:Zero-cost futures in Rust by dbaupp on Thursday August 11, 2016 @04:09PM (#12271245)
Lambdas in C++ are almost identical to Rust ones (each closure is a unique unnameable struct containing the captures, with an overloaded operator()), in fact, the current Rust scheme was explicitly inspired by C++11 closures. Historically (C++98), it's true that not much code used closures, because they didn't exist at a language level, but the modern language uses them much more aggressively, even pushing hard on making them more and more flexible (e.g. auto/generic closures in C++14). For instance, sort[1] can take a closure which is more efficient that way than a function pointer, and easier to use than a manually implemented custom type.

Also, closures are just structs with functions that take them as arguments, so if the compiler can handle those, it can handle closures.

[1]: http://en.cppreference.com/w/cpp/algorithm/sort

Re:Zero-cost futures in Rust by gpderetta on Thursday August 11, 2016 @05:05PM (#12271529)
Exactly. And hand written function objects were already common in C++98. C++1* lambdas are just (very sweet) syntactic sugar.
Re:Zero-cost futures in Rust by int_19h on Thursday August 11, 2016 @04:01PM (#12271184)
Lambdas in modern idiomatic C++ are also essentially zero-cost, or at least they're supposed to be - they're not heap-allocated, and are strong candidates for inlining.