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.

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

Exactly. And hand written function objects were already common in C++98. C++1* lambdas are just (very sweet) syntactic sugar.

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.

Does clang directly go for LLVM or is there an intermediate form that is optimized similar to MIR?

I believe it goes straight to LLVM IR.

Yeah, I meant the latter, sorry.