Of the xxx_exactly variants, only drop_front_exactly is kept for now,
because it actually allows an optimization. The other ones did not
really provide a compile-time improvement, so they are removed.
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
Also:
- Remove the boost_hana_add_executable function, which is now useless
- Properly set the LD_LIBRARY_PATH to link against a custom libc++
- Adjust the Travis build
Fixes#135
Properly providing operators for users was too complicated, and it is
judged as being out of Hana's scope.
Instead, operators are now provided by helper classes in the detail::
namespace. Now, we can be as dirty as we want, since it is not part of
the interface anymore.
Fixes#138Closes#30
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 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.
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.
- Move Functional to Details, to get more time to think about it
- Move Either to Details, to get more time to think about it
- Prettify some examples
- Better introduction of the "Data types" documentation module
- 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.
- Fix ambiguous specialization in core/datatype
- [Config] Turn #errors into #warnings
- Qualify recursive calls to `apply` to make sure the right function is selected
- Remove usages of when_valid to workaround ambiguous specializations
- Use multiline comments to remove some GCC warnings with LaTeX's double backslash
- Specialize operators::of in the boost::hana::operators namespace
- Manually perform more conversions in constexpr-context
- Workaround the lack of support for constexpr-but-non-const member functions
- Disambiguate unqualified uses of size_t with hana::size_t and ::size_t
- 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
- Define the notion of move-independence, thus relaxing the requirements on accessors.
- Rename `members` to `accessors` and use `members` to get the members only
- Document the different ways of providing a model
- Make the model of Foldable more consistent
Fixes#53
- Rename bind to chain
- Rename mcompose to monadic_compose
- Rewrite a large part of the documentation
- Document the limit on the arity of functions used with monadic_compose
Fixes 48
Fixes 9
- Make decltype_ the identity on Types
- Add the alignof_ function
- Allow sizeof_ to work with non-Types
- Remove the trait_ helper
- Allow Metafunctions to be called with non-Types
- Add make<Type>, which is equivalent to decltype_
- 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.
- Improve the documentation and tests of Lazy
- Add missing `operator!` to Logical's documentation
- In `eval_if`, evaluate branches with `eval` for more flexibility
- Use `lazy` instead of ugly workarounds in Sequence and Iterable
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.
