2) As for local functions, namespace, or global structs see N2511. If you disagree with N2511 arguments, it's truly OK because IMO everyone is free to use whatever idiom they see fit for themselves and their problem domain. I am sure the library reviewers had namespaces and global structs in mind when they assessed the "potential usefulness of the library" (also because these are mentioned in the library docs). So also in this case /all/ submitted reviews should allow the review manager to come to a conclusion on this issue.
Sure, but again I don't see what's in N2511 that's not doable with C++11 lambda's.
So in no uncertain terms am I expressing my opinion in the context of this thread that for libraries like Local, *no*, this should not be a library but rather should be a proper language extension for it to provide any real advantage over whatever is already out there and especially what's already in C++11.
You are conflating two different arguments over and over again: 1. Whether Boost.Local provides any advantage over pure C++03 alternatives 2. Whether it is appropriate to add something to Boost that improves the C++03 experience but has been obsoleted by a C++11 feature Can we please keep these discussions separate and argue them on their own merits? It doesn't help when every time someone refutes your position about (1) you bring up (2) saying that it makes (1) irrelevant. We already know your position about (2): that now C++11 is here, we should be moving on and stop giving attention to C++03 problems which are solved by C++11. I, on the other hand, think the reality is that C++03 will be around for a while longer, and it's worth caring about the C++03 experience evem if there are C++11 solutions. Obviously our positions are derived from different experiences working with C++, and I don't think there's much point arguing about this, other than asking others to weigh in and share their positions based on their experiences.
3. I cannot, no matter how I look at your examples and the "logic" behind the concept of local functions, comprehend why this is a good way to organize code. Aren't we all past the phase yet of functions that have more than 10 lines of code?
The advantages of having a function (a logical piece of code that's meant to be used as a unit *anyway*) at namespace scope or class scope is that re-usability is something you get for free. On the other hand, defining a local function with Boost.Local that I'd want to define as an external function at some point (because oh I don't know I want to use the same function somewhere else all of a sudden) will be too much work with all the macro voodoo that I have to wade through.
I think this is a matter of one's coding style. When I write a function, I think of it as being part of some interface. It if it's a public method of a class, it's part of the class's public interface. If it's a private method, it's still part of some interface: the interface used by the implementations of the public methods. By moving a function A from being local to another function B, to being in the same scope as B, you are adding function A to the same interface that function B is part of. I view this as a design choice: a choice I may or may not want to make, and I wouldn't like the langauge to stand in my way and force me to make one choice because it doesn't support the other. So, at least in my coding style, I see a use case for local functions which does not have a C++03 solution. I think a language, and C++ in particular, should be flexible enough to accomodate different coding styles. Now given that we don't have language-level support for local functions in C++03, the next best thing we can do is emulate it with a library.
Hey I'm not complaining that people are bashing libraries. What I'm complaining about is why people aren't complaining (meta isn't it?) that their compilers suck at displaying better error messages for broken code.
Again, *THE LIBRARY DOESN'T SPEW ERROR MESSAGES, COMPILERS DO THAT FOR BROKEN CODE*.
So again, how does broken code using any library become a basis for whether the library is a good library for inclusion in Boost? It just seems silly to me.
The problem is that errors point to code that is deep within the library's implementation, or worse, the implementations of helper libraries used by the library. To understand the error, the user has to look at the library's implementation. The user shouldn't have to do that - understanding the implementation of a library should not be a prerequisite for using it. If you have any specific suggestions about what compilers could do to turn these errors from deep within the library implementation, into errors that do not require knowing anything about the library implementation, I would like to hear it, and I'm sure so would compiler writers. Otherwise, you have to accept that library writers face a trade-off between the user-friendliness of error messages, and the expressiveness, terseness, and power obtained by extensive use of advanced techniques such as template metaprogramming. There is no one right answer to this tradeoff, and it is good for users to have different alternatives available to them. Regards, Nate