Please let me clarify my vote again. Please also note, that the quality of the implementation and documentation is out of doubt. I vote to not include Boost.Local into Boost for the following reason. I obviously can not appreciate the value of local functions in C++. C++, IMHO, has better ways to structure code (namespaces and classes). Therefor, Boost.Local is not an alternative to C++-Lambdas, Boost.Bind, Boost.Lambda or Boost.Phoenix, but to regular C++ functions That being said, I don't see Boost.Local as a complement to the other already existing functional programming style libraries. I see it as a complement to regular functions. It is true that this implementation of local functions leads to function objects that can be used as callbacks where something callable is expected. However, that does not mean that they are higher order functions, which in turn means that they are not easily composable (that means, there is no way to compose two local functions to form another local function other than calling the macros again). Which has another side effect that they are completely incompatible with the existing solutions (ok, you can bind them again). Also, i think the verbosity of the macros defeat their initial purpose of "avoiding cluttering other parts of the program with functions, variables, etc unrelated to those parts". Additionally I can not see how local functions hide any information at all, the information is still visible (although hidden behind two enclosing, quite verbose, macro calls). I admit the fact, that we as C++ Programmers need Macros to avoid repeating ourselves (aka boilerplate code). A lot of libraries do exactly this, and it is considered good practice. My main point of critique was that the Boost.Local seem to implement a quite complex logic and, basically, their own language. I would not consider the preprocessor the proper place to implement a DSEL. Again, Lorenzo's effort and ingenuity of creating this very library is out of question, I solely believe that it is not the proper solution to this problem.