Note: I've changed the title of the email because this part of the discussion is not related to Boost for C++11 or C++03. On Wed, Nov 23, 2011 at 6:21 AM, Joel de Guzman <joel@boost-consulting.com> wrote:

On 11/23/2011 5:53 PM, Lorenzo Caminiti wrote:

...

...

we should do is push the C++ compiler writers to give us library writers

...

more power to address the problems such as the often cited deluge of undecipherable error messages. TMP libraries are ubiquitous in modern C++. Avoiding them because of the problem of error messages is backwards thinking. What we should do instead is to find better solutions, not hide the problems.

This is Boost!

...

How is a library like Boost.Algorithm pushing the limit? It's a very

How did you arrive at that? I said:

"what we should do is push the C++ compiler writers to give us library writers more power to address the problems such as the often cited deluge of undecipherable error messages."

Please read that again. You've mixed that with what I said earlier:

"Keep in mind that Boost has been at the forefront of C++ library development. It is because of these libraries that push the limits of C++ that we see the advancement in C++ that we enjoy now in C++11."

I never said that all libraries in Boost push the limits of C++.

I see, yes that is what you wrote for example here "what we should do is push the C++ compiler writers to give us library writers more power to address the problems such as the often cited deluge of undecipherable error messages". I miss read your email, I didn't understand that it was pushing the limits of compilers to give library programmers more control over error detection/reporting. Thanks for the clarification.

All the rest of your reply is irrelevant.

Well, no. The following part of my reply is now even more relevant because it repeats that Local is not just about (2) better error messages (your point above about pushing the limit) but also about (1) usual statement syntax for the function body (which every programmer in your team will understand at once).

...

the syntax presented there. Proponents of locals have cited error-messages generated by the compiler as a justification for Locals. Locals is probably a good workaround. But hear me out...

Nope, not just a good workaround for error-messages. Proponents of Locals mentioned two (2) main things as advantages. Please let's cite both of them correctly: 1) Use statement syntax for function definition. 2) Compiler error retain their usual meaning for the function definition. While these two things are related from an library implementation prospective, they are two different advantages for the library end-user.

The politically correct sentence fro the docs: "[Local functions] can be defined using C++ statement syntax plus eventual compiler errors follow the usual format of C++ statement errors". https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca...

--Lorenzo