The `models<>` machinery added unnecessary complexity for little benefit.
Also, this makes Hana's concepts syntactically closer to concepts lite,
which should contribute to making them easier to grasp at first sight.
Precisely,
1. Rename hana::_type to hana::basic_type, and document it
2. Rename hana::type<> to hana::type_c<>
3. Create and document the hana::type<> type
- Fix ambiguous overload of `concat` for Optionals
- Fix compilation error in std::vector unit test
- Fix false positives related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66543
- Fix compilation error caused by variable template initialized by a lambda
- 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
The Fusion adapters have been giving me trouble for a long time now.
The problem is that Hana's unit tests are more thorough than Fusion's,
and hence we keep uncovering Fusion bugs through Hana's unit tests.
This keeps on breaking the build and makes me lose valuable time trying
to workaround these bugs until they are fixed in Fusion's master branch.
Therefore, only the methods that are implemented by Fusion adapters are
tested to make sure they work as expected, but the other algorithms that
are derived from them are not tested on Fusion adapters.
- Replace init by drop_back and drop_back_exactly
- Rename head to front
- Rename last to back, and also rewrite the default implementation
in terms of at instead of using (inefficient) recursion.
- Rename drop[_exactly] to drop_front[_exactly]
- Remove drop_c
Note that tail is kept for the moment because it is part of Iterable's
MCD. Removing tail will be the subject of a different issue.
Fixes#66
That concept was added more for completeness than for actual usefulness,
since I have not used it a single time since its creation. Given the
complexity of the library, I think it is better to remove it and shrink
the library to a more useful core than giving too many features that
contribute to bloat.
Also, the laws were difficult to check and it hence Traversable models
were not very well tested anyway.
I can always roll this back if someone shows me how Traversable is
actually useful for metaprogramming.
- Properly setup build matrix
- Clean up .travis.yml
- Try building with Boost 1.57 and Boost 1.58
- Install dependencies to the deps/ subdirectory
- Reduce memory usage of test/type.cpp
- Re-enable some Fusion tests
This is because using variable templates limits the objects to being
constexpr, or to not being constexpr (but then initializing the object
becomes an issue).
This is also a step towards being compilable by GCC 4.9, but that only
would not justify the change.
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.
- Split type class instances into separate files
- Instances provided automatically by a type class are actually MCDs
- Test each instance in a single file, not one file per method
- Refactor the operator system to fix the ADL-related bug.
