Re: [boost] "Simple C++11 metaprogramming"

Subject: Re: [boost] "Simple C++11 metaprogramming"
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2015-08-22 17:37:29

2015-08-22 8:43 GMT-03:00 John Bytheway <jbytheway+boost_at_[hidden]>:

> On 2015-08-20 19:50, Bruno Dutra wrote:
> <snip>
> > Now lets imagine the user nonetheless tries to evaluate a metafunction
> that
> > instantiates to "nothing". The only error the compiler will raise will
> look
> > similar to the following:
> >
> > error: no type named 'type' in 'struct metafunction<args...>'
> >
> > That's it, no scary internals exposed.
>
> I'm not so sure that's wise.  These "scary internals" are often vital
> hints to debugging when code isn't doing what you expect.  How confident
> are you that such is not needed here?
>
> John Bytheway
>
>
How confident are you that "scary internals" provide any better hint than
the actual list of arguments that were used to instantiate the affected
metafunction?

Now seriously, allow me to elaborate. Suppose the user provides an invalid
set of arguments to some metafunction, say a fundamental type where a list
is expected, and this invalid set of arguments is allowed to be blindly
forwarded ever deeper up to a point where some error is triggered.
Invariably, the first error reported by the compiler would be about some
undocumented internal template which can't be instantiated for some set of
arguments that, in turn, are often totally unrelated to what the user is
trying to do. All while the actual metafunction instantiated by the user,
together with the invalid set of arguments that are in fact behind the
everything, would be dozens of lines bellow, hidden among multiple other
[probably unexpected] metafunction instantiations. I fail to imagine how an
error message could be more misleading than this.

Assuming the library is free of bugs, the error must have its roots in the
set of arguments provided by the user, so that's the first thing the user
should check and is usually the user's only hope of figuring it out. That's
precisely the very first thing I make sure the compiler outputs as part of
its error message.

In my own experience, every time I abuse MPL, I find myself scrolling past
dozens and dozens of incomprehensible, and worse yet, recursive template
instantiations, looking for the actual metafunction instantiation that
triggered the error. It's not fun at all.

Bruno