Initially, this commit was supposed to provide a slightly
optimized version of `find_if` for `integer_sequence`.
Unfortunately, benchmarking did not show any significant
difference, and so the current implementation will be kept.
Benchmark data is here: http://pastebin.com/t3M8YwzD
Note that no `norm` function is added for now, since the `norm` is not
tied to the specific Euclidean ring as explained in [1]. However, it
might be useful to enforce an arbitrary choice to be made for each
Euclidean ring. This could perhaps be added in the future.
Fixes#28
[1]: https://en.wikipedia.org/wiki/Euclidean_domain#Definition
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
- 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
