Le 07/03/15 19:09, Louis Dionne a écrit :
Louis Dionne
writes: Vicente J. Botet Escriba
writes: [...]
Compile-time error reporting --------------------
I would expect that the library provide some king of "TypeClass" check use (As Eric's Range library does with Concepts) so that the compile time errors are more explicit. Doing this for all parameters of all functions is intractable due to the heterogeneous context, but basic support could be added easily. I'm promoting this on my todo list. Before I go an change the code, I'd like to make sure I understand your comment properly. Currently, if you use a method with a parameter that does not model the required concept, you'll get an assertion. For example,
hana::head(1);
Produces
[...] error: static_assert failed "no definition of boost::hana::head for the given data types" static_assert(wrong
{}, ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~ [...] note: in instantiation of function template specialization 'boost::hana::head_impl ::apply<int>' requested here return head_impl ::apply( ^ [...] note: in instantiation of function template specialization 'boost::hana::_head::operator()<int>' requested here hana::head(1); The check is currently being done in the base case of the tag-dispatched method, `head_impl`. It could also be done higher up, in the "interface method", i.e. `head` itself. For example, here's what I experimented with locally:
hana::head(1);
Produces
[...] error: static_assert failed "hana::head(xs) requires xs to be an Iterable" static_assert(models
{}, ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [...] note: in instantiation of function template specialization 'boost::hana::_head::operator()<int>' requested here hana::head(1); Is this the kind of improvement you were talking about, or was it something else entirely? Regardless, I like this better than my current system and I'll probably do it, but I'd like to make sure I understand your point.
Yes, this is exactly what I would expect. Report errors at the interface level, not the implementation. Vicente