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.
Louis
