- Allow specializing models_impl with a forward declaration only
- Modularize remaining concept headers
- Include <boost/hana.hpp> in unit tests to ease the transition
- Add the core/dispatch.hpp header to reduce the number of boilerplate includes
This (large) commit introduces the following changes:
- Each algorithm lives in its own header
- The concepts are defined in the concept/ subdirectory. They define the
`models` metafunction, some explicit default implementations (like
Applicative::transform_impl), and they include all the algorithms
related to that concept.
- Removed the `until` method from Logical
- Removed the `drop_until` method from Iterable
- [minor] Added the detail::nested_to utility
Closes#160
There was a legitimate reason to have this duplication when the library
was much smaller. However, hovering at about 30 kLOCs, the library is
definitely not small enough anymore to mandate reimplementing our own
<type_traits>. Also, most user code will probably include <type_traits>
anyway, so using <type_traits> will not increase the overall compilation
time in actual code bases.
Finally, this gives us much more flexibility, like the ability to
inherit our IntegralConstant from std::integral_constant, and then
return that from the traits:: metafunctions, so that operators can
be used with them.
This essentially undo parts of 307d3d0. While it seemed a like good
idea to over-modularize type classes to reduce header dependencies, I
think it was a mistake. What 307d3d0 did was basically split each of
the components of a type class into a single header (typeclass/operators.hpp,
typeclass/mcd_1.hpp, typeclass/mcd_2.hpp, ...).
At first, it resolved many weird header dependency glitches. However, it
also made everything more complex; creating even easy type classes was
sometimes much longer than it should have been, and using type classes
was tricky because you had to know exactly what to include. It also went
against the idea of implicit type class instances being provided whenever
that's possible, which I think is a nice feature of the library. Being
dissatisfied with this, I opted for a simpler header organization with
a fwd/ directory that contains forward declaration headers, and everything
else in the same directory.
A possible objection to this change would be that you are now forced
to include sometimes more than what you strictly need when e.g. defining
an instance or using only some instance(s) of a data type. My answer to
this is that Hana is a really small library and the parsing is not
going to have a huge impact on overall compilation time. My bet is that
the time that will be saved by programmers with a simple header hierarchy
outweights the parsing time by far.
