This was annoying because
(1) We couldn't use the name hana:: from within the struct
(2) It requires one more instantiation unless you use the
`using hana = self` trick. But that trick makes something
that should be trivial to do slightly harder, and that is stupid.
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
- 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
libc++'s std::pair always has a default constructor, and it is ill-formed
when the members are not default constructible. We need it to be SFINAE
friendly. See https://llvm.org/bugs/show_bug.cgi?id=21917.
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
- 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
This is done because the resulting macros are much more straightforward
to debug when a user makes a mistake. Also, it avoids pulling yet another
dependency.
Also added some general purpose macros in detail/preprocessor.hpp.
- Improve the brief description of make<XXX>
- Rewrite the rationale for unspecified container types
- Update comments on some runtime benchmarks
- Rename std::decay_t(...) to std::decay_t<...> in Tuple reference
- Document data types as being Tags, not types themselves
- Extend the Quick Start with more small examples, and then the large
switchAny example.
- Add clarifying remarks right in front of the CheatSheet for skimmers.
Damn skimmers.
- Benchmark the compile-time of creating std::array
- Remove the preface entirely
- Move the current introduction to a "Description" section
- Move the "Quadrants of computation" to the "Introduction"
- Move the current "Motivation" section to the start of the "Introduction"
- Move the section on "Introspection" higher up in the docs
- Remove the "Concept" column in the Cheatsheet, and add links to each
individual algorithm instead.
- Add a rationale for unpack's name and parameter order
- Add `fold` and `reverse_fold` to the cheatsheet
- Mention the list of all headers in the tutorial
- Add an alphabetical index with everything in the library
- Precise that smaller is better in chart subtitles
- Add benchmarks for std::make_tuple and std::get
- Add an "Acknowledgements" section
- Rename Boost.Hana to Hana for now (not officially a Boost library)
- Partially write the section on "Introspection"
Fixes#46
I feel like the documentation now provides enough real world examples:
- switchAny
- Euclidean distance
- JSON generation (to be written)
- MPL reimplementation
- Merge section on Amphibian Algorithms with section on Algorithms
- Replace the `decayed` pseudo-code by `std::decay_t`.
- Rewrite and move section on type computations
- Add Appendix on the MPL implementation
- Write sections on containers, algorithms, and runtime performance
- Make sure examples consistently use 2 space tabs
- Disable -Wunused-parameter for examples
- Resolves#70
The requirement of pure functions is now documented.
- Resolves#14
It turns out that the benefits of specifying the type of containers
seems to be essentially limited to pattern matching. This is not
enough to justify all the bad things it brings, especially
considering the fact that recursion (currently the only use
case for pattern matching) forces the creation of a new tuple
at each step, which is disastrous. The unspecified-ness of the
container's type is now documented.
- Rename elem to contains
- Rename subset to is_subset, and make is_subset applicable in infix notation
- Add the at_key method
- operator[] is now bound to at_key instead of find
- Rename fold{l,r,l1,r1} to fold.{right,left} with overloads.
- Rename foldlM/foldrM to monadic_fold.{left,right}
- Add no-state variants of the monadic folds
- Improve the fold's documentation
- Deprecate the previous folds; they'll be removed soon
Fixes#18.
