[boost] [local] not just "better" error messages (was: Re: New libraries implementing C++11 features in C++03)

Subject: [boost] [local] not just "better" error messages (was: Re: New libraries implementing C++11 features in C++03)
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-23 06:39:13

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_at_[hidden]> 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_local/Alternatives.html#boost_local.Alternatives.local_functions

--Lorenzo