One suggestion for the future, although I am not sure how useful it would turn out in practice is to have something like local expression, or even not necessarily a local one. This would be a function whose body consists of a single expression. The benefit you get is that the programmer does not need to specify a return type for it (you can use BOOST_TYPEOF for that), or doesn't even have to type keyword 'return', but this may be too much off topic. Can you clarify with an example?
In C++11 lambdas do not require specifying the return type, provided that the body of the function is a single return statement: because it is easy to deduce the type from such single return statement. Similarly, for Boost.Local if a function body consists of a single return statement you could (I guess) provide a more simple syntax. Instead of BOOST_TYPEOF(sum) & BOOST_LOCAL_FUNCTION_PARAMS( double num, const bind factor, bind& sum ) { return sum += factor * num; } BOOST_LOCAL_FUNCTION_NAME(add); I could write: BOOST_LOCAL_EXPRESSION_PARAMS( double num, const bind factor, bind& sum ) BOOST_LOCAL_EXPRESSION_END( add, sum += factor * num ); You save me typing the return type and 'return' keyword. But now that I have written it down I do not think it is particularly useful.
I think in a nutshell the conclusion (which I will detail in the rest of my comments below) was that Boost.Local is handy but on compilers with C++11 lambdas you'd just use lambdas. At the same time, Boost.Local allows you to write local functions that work also on C++03 compilers and that have the same compile-time and run-time performances of lambdas on C++11 compilers. So the /main/ audience would be someone (like myself) that wants to do local function stuff and expects lambda-like performances on C++11 but also has to deal with C++03 compilers. There are other benefits like const& binding which is not supported by C++11 lambdas (so how can I bind by const a variable that has a very expensive copy constructor using C++11 lambdas?) and improve scope exit (i.e., local exit) but these other benefits are probably minor in the general domain (they can be very important or even essential is a specific and narrow domain like Contract Programming but not critical in the general case).
OK Lorenzo, I am convinced. Can we trade? I will vote 'yes', and you will add a motivation section in the documentation which will stress that the primary motivation of the library is to provide a uniform (in terms of syntax) support for local functions: fast and 'native' for C++11 compilers, and acceptable (using tricks) in older compilers. The library can be used directly or be a foundation for higher level libraries like Boost.Concept. Review Managers, I am not really trading, I vote YES for the Boost.Local and just request the motivation section in the documentation. I think the situation of Boost.Local is similar to that of Boost.Move, and the latter was accepted into Boost. Also, having a library in Boost whose primary purpose is to serve as the foundation for other Boost libraries is not a precedent (I mean Boost.Proto and now Boost.Context). Regards, &rzej