These are chat archives for boostorg/hana

21st
Jul 2016
Jonas Platte
@jplatte
Jul 21 2016 00:00
oh wait
I think that's not actually the function the compiler is complaining about
Oh now it is..?
Anyway the other one looked almost identical
So this is one of the messages in the error backtrace of the compiler:
note: in instantiation of function template specialization 'algebra_cxx14::guard<bool, (lambda at ./algebra_cxx14/subtraction.hpp:51:43), std::integral_constant<bool, true>,
      (lambda at ./algebra_cxx14/subtraction.hpp:52:43), std::integral_constant<bool, false>, (lambda at ./algebra_cxx14/subtraction.hpp:53:43)>'
guard is exactly the function I posted on github gists
I'm pretty sure the cause of the problem is the first template argument being bool, not integral_constant<bool, something>
Jonas Platte
@jplatte
Jul 21 2016 00:06
is_term is defined like this:
template <typename T, typename = void>
struct is_term_ : std::false_type { };

template <typename T>
struct is_term_<T, void_t<eval_t<T>>> : std::is_base_of<term<eval_t<T>>, T> { };

constexpr auto is_term = hana::compose(hana::trait<is_term_>, hana::decltype_);
Got a tiny repro!
This errors with no viable conversion from 'bool' to 'hana::false_':
#include <boost/hana.hpp>
#include <type_traits>

namespace hana = boost::hana;

auto is_pointer = hana::trait<std::is_pointer>;
auto wrong = is_pointer(hana::type_c<int>);

hana::false_ x = wrong && wrong;
Jonas Platte
@jplatte
Jul 21 2016 00:12
I guess this is because hana::trait doesn't convert from std::integral_constant to hana::integral_constant?
And of course std::integral_constant<bool, ...> is implicitly convertible to bool, so it will happily apply operator&& >_>
Jonas Platte
@jplatte
Jul 21 2016 00:23
Well I guess that's a good reason to also use hana for the classic type traits
Jason Rice
@ricejasonf
Jul 21 2016 00:26
It would work if you used hana::and_(wrong, wrong).
(i bet)
Jonas Platte
@jplatte
Jul 21 2016 00:26
No, I tried that as well
The documentation also says it's very generic, so it's probably just a && fold.
and either operator&& or and_ is specialized for hana::bool_, but not for std::integral_constant<bool, B>.
Jason Rice
@ricejasonf
Jul 21 2016 00:30
It doesn't really help to assign to a stateless type like hana::false_. Just use auto...
auto x = hana::and_(wrong, wrong);

BOOST_HANA_CONSTANT_ASSERT(x);
Jonas Platte
@jplatte
Jul 21 2016 00:31
But it was a lot shorter to write than any form of assertion (also I hate macros)
Jason Rice
@ricejasonf
Jul 21 2016 00:32
static_assert(decltype(x)::value, "");
Jonas Platte
@jplatte
Jul 21 2016 00:32
It's just a thing I wrote in a minute to try to reproduce the error. I don't see how static_assert is better here. It takes longer to write ^^
Jason Rice
@ricejasonf
Jul 21 2016 00:37
I see what you are trying to do, but auto is generic hana::false_ is not. I guess it would work if you used hana::traits::is_pointer. http://melpon.org/wandbox/permlink/l7yeWbaatNPe2OMP
Jonas Platte
@jplatte
Jul 21 2016 00:38
Again, is_pointer is just to reproduce the error without all the stuff from my actual library. And I've already found the problem and am using hana::bool_ instead of std::integral_constant<bool, B> now.
(the equivalent of using hana::traits::is_pointer instead of hana::trait<std::is_pointer> I guess)
Would be nice if hana::trait converted std::integral_constants into hana::integral_constants though
Jason Rice
@ricejasonf
Jul 21 2016 00:44
hana::traits::detail::hana_trait does :P
Jonas Platte
@jplatte
Jul 21 2016 00:44
Is any of the hana::traits in the documentation? I can't find it..
Jason Rice
@ricejasonf
Jul 21 2016 00:44
I'm not sure why hana::trait wouldn't
I don't think it is. I wouldn't rely on detail stuff either. I was jk
Jonas Platte
@jplatte
Jul 21 2016 00:46
Yeah I got that, but you mentioned the hana::traits namespace a few times now and I can't see it in the docs.
Jason Rice
@ricejasonf
Jul 21 2016 01:35
it probably should be
Jonas Platte
@jplatte
Jul 21 2016 03:36
Aaand I'm on git master...
for some reason decltype_ caused really annoying problems that I still don't understand, switching to typeid_ fixed it (somewhat magically ^^)
Jason Rice
@ricejasonf
Jul 21 2016 03:39
decltype_ doesnt strip const
Jonas Platte
@jplatte
Jul 21 2016 03:40
Okay.. That could have been the issue. filter seemed not to select elements as matching with the same predicate that count_if selected elements with
Jonas Platte
@jplatte
Jul 21 2016 04:11
@ldionne So this took me all night but I'm finally done porting my library to hana. If you want to have a closer look at how I'm using it, it's now on GitHub (https://github.com/jplatte/algebra-cxx14)
Louis Dionne
@ldionne
Jul 21 2016 04:19
@jplatte Thanks a lot. A night is not too long, but how do you think that went?
Regarding hana::trait, the reason why it’s not converting anything to hana::integral_constant is that you’d be pissed off if the result of a trait being mpl::integral_c or std::integral_constantwas actually relevant (e.g. for tag dispatching) and Hana converted everything to hana::integral_constant.
That would break your code.
Jonas Platte
@jplatte
Jul 21 2016 12:02
Actually it was like all day + all night :D
It was kind of painful to have count_if and filter disagree on which elements matched a predicate.. I got a lot of errors because the compiler got into endless recursion.
Jonas Platte
@jplatte
Jul 21 2016 12:26
I also got many endless recursions in the compiler because I didn't properly guard some of my eval_if branches with _(). Not doing that in my guard function meant that all the branches for which there was a true condition were evaluated, instead of just the first one with a true condition. Also it meant that the static_assert(_(false), "Non-exhaustive guards!"); was evaluated whenever the last guard condition was false, not when all of them were. That took forever to debug.
All in all I'm happy with how much more readable my code is now, but I didn't see much of the friendly error messages. It did error early when I tried to compare a hana::size_ with another integral constant created by operator""_c, but that's about the only time I remember actually hitting a static_assert outside of my own code (and there I would actually have preferred it just to work.. Or is it impossible to compare integrals of different types at compile time?)
Jonas Platte
@jplatte
Jul 21 2016 12:32
So yeah.. hana::trait wasn't the worst ^^
Louis Dionne
@ldionne
Jul 21 2016 14:36
You can compare two integrals of different types, but not when that could incur a lossy conversion, i.e. int == unsigned int could be lossy if unsigned int was too large.