MSVC doesn't like the #warning directive and issues a fatal error.
It also sets _MSVC_LANG to 201402 for C++14 instead of __cplusplus,
but that's the minimum value anyway.
It also doesn't like using {} instead of ::value for some type traits
sometimes and issues an error about a missing default constructor.
[ldionne: add full break after first line in commit message]
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.
- 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
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
- 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
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.
