2015-08-22 8:43 GMT-03:00 John Bytheway
Now lets imagine the user nonetheless tries to evaluate a metafunction
On 2015-08-20 19:50, Bruno Dutra wrote: <snip> 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
' 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