The example/tap.cpp bug was actually interesting, so I'll document it
here. We were using `tap` with a function that performed side effects.
However, we relied on the side effects being done in a particular order
for the example to pass. This is a violation of what the documentation
says we're allowed to.
On Windows, the call convention is such that arguments are evaluated
from right to left, instead of left to right like on OS X and Linux.
Since `chain` uses `transform` and `transform` expands `f(x)...` inside
a function call, our function with side effects was being called in
reverse order as what we would have expected!
Morale: Listen to the documentation, or perish.
The commits are db487b2b4 and 76a0ac16a. They were supposed to fix
unit tests failing on Windows due to a missing EBO, but both of these
commits failed to do so. Since I can't test on Windows by myself for
the time being, I'm rolling back these commits and I'll try to fix
this error later.
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
Also, make existing Constants models of IntegralConstant. This fixes#132
by making the definition of a model of Constant reasonably easy for
IntegralConstants.
Also, swap the project() and the cmake_minimum_required() commands
in the top-level CMake file, as this silences a warning when building
on Cygwin. See #168.
- Promote the `Tree` experiment to an example
- Remove sandbox/string.cpp; which is nothing but string_view
- Refactor the Function example so it does not use exceptions
- Remove llist.cpp, which is a mostly uninteresting experiment
- Remove sandbox/array.cpp, which is essentially sprout::array
(see https://github.com/bolero-MURAKAMI/Sprout)
The hidden goal of this commit is also to setup the place for building
without exceptions, by removing or modifying the tests that required
them.
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.
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.
- Use basic_tuple instead of closure<> for the inner storage
- Make sure the assignment operators are constexpr
- Copy the unit tests from closure<> (closure will eventually be removed anyway)
Fixes#165
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
I had been unsatisfied with Either for a while now, thinking it might
be useless. I am now convinced that it is useless, and I hence remove
it from the library altogether.
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.
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.
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
Also,
- Document the fact that the default `unpack` is inefficient
- Give a single implementation of `length` in terms of `unpack`
- Doxygen: product = see documentation
Fixes#108
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.
- Make sure the check.benchmarks are serialized
- Run Doxygen with Clang 3.6 instead of Clang trunk
- Download prebuilt Doxygen instead of building from source
- Run unit tests on two cores
This commit fixes issue #75, but it does not fix the related issue #76.
It only makes sure that function objects are not defined multiple times,
but does not ensure the uniqueness of the addresses of the function
objects, which is much harder to get right.
Fixes#75
- 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
