Subject: Re: [boost] TMP error messages [ was Re: New libraries implementing C++11 features in C++03 ]
From: Ábel Sinkovics (abel_at_[hidden])
Date: 2011-11-26 08:22:32
Hi,
> 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.
We've been experimenting with returning error messages from TMP
libraries that make sense in the domain of the library. Our approach is
returning a class describing the error when a metafunction is called
with invalid arguments (a pretty-printer can display that information
later in a human-readable way). The assumption is that this error
information is returned by a metafunction deeply inside the TMP library
and need to be propagated out (maybe changed a bit along the way to make
more sense to the user). For this we've used monads, using which we
could simulate exceptions being thrown at compile-time. Using monads
increases the complexity of the TMP library, however, most of it can be
hidden by another library. We've been working on such a library (not in
Boost).
What TMP library authors can do is wrapping the body of every
metafunction with a template that "adds" error propagation to it. For
example instead of:
template <class A, class B, class C>
struct some_metafunction_in_the_library :
f<g<A, C>, h<B>, A>
{};
one can write
template <class A, class B, class C>
struct some_metafunction_in_the_library :
try_<f<g<A, C>, h<B>, A> >
{};
in which case if f, g or h returns an error, the same error is returned
by some_metafunction_in_the_library instead of breaking the compilation
with a cryptic error message. At the top level it can be pretty-printed
by a test harness (eg. simple binary built to pretty-print it or by a
TMP unit testing framework). A downside of using it is that it makes
compilation slower (see
http://plcportal.inf.elte.hu/en/publications/TechnicalReports/monad-tr.pdf
for measurements).
So far we've only been using it for improving error messages coming from
template metafunctions. Cases where they can't be easily and clearly
separated from runtime code haven't been addressed yet.
This solution is part of a library implementing monads in C++ template
metaprogramming.
Documentation: http://abel.web.elte.hu/mpllibs/metamonad/index.html
Source code: https://github.com/sabel83/mpllibs/tree/master/libs/metamonad
Note that there are only a few examples so far.
Regards,
Abel