These are chat archives for boostorg/hana

25th
Nov 2015
Jason Rice
@ricejasonf
Nov 25 2015 03:42
Sorry if that is a whole can of worms. I think I get that f could be an rvalue and this maintains that status.
Jason Rice
@ricejasonf
Nov 25 2015 22:23
Just at first glance, I see an unnecessary use of hana::to<tuple_tag> being called on a tuple.
Maik Klein
@MaikKlein
Nov 25 2015 22:26
I am super new to hana and this was in the docs
Jason Rice
@ricejasonf
Nov 25 2015 22:31
If you take that example and strip that use of to it still works. I wonder why it is there.
Maik Klein
@MaikKlein
Nov 25 2015 22:37
no idea, but do you see any obvious mistakes in my example?
Jason Rice
@ricejasonf
Nov 25 2015 22:39
I think it could be simplified. There is a contains function... one sec
Maik Klein
@MaikKlein
Nov 25 2015 22:39
I also used the contains function with the same result
template<class... Ts, class T>
constexpr auto contains_test(T&&){
  auto types = hana::to<hana::set_tag>(hana::tuple_t<Ts...>);
  return hana::contains(types, hana::type_c<T>);
}
oh
I have found the problem
I used T&&
and it works with just T
obliviously the && is not necessary, but I still wonder why it results in that behavior
ah
Maik Klein
@MaikKlein
Nov 25 2015 22:44
maybe hana::type_c<T> will then be of type T&?
Jason Rice
@ricejasonf
Nov 25 2015 22:45
I think you can use decltype_ for reference stripping.
Maik Klein
@MaikKlein
Nov 25 2015 22:47
Tested it, that was the problem. It works with hana::traits::remove_reference. but I just leave the &&
Jason Rice
@ricejasonf
Nov 25 2015 22:54
probably just use T right?
Maik Klein
@MaikKlein
Nov 25 2015 22:55
yeah
Jason Rice
@ricejasonf
Nov 25 2015 22:59
If you answer your own question, it would be good to emphasize that hana::type_c<T> != hana::type_c<T&&>, eventhough you don't really need T&&.
Maik Klein
@MaikKlein
Nov 25 2015 23:01
I think it's actually T& because of lvalues
strangely enough it works for rvalues
Jason Rice
@ricejasonf
Nov 25 2015 23:03
oh right
weird
Maik Klein
@MaikKlein
Nov 25 2015 23:04
maybe its because
the rvalue of an int&& is actually an int?
because it just gets copied?
Jason Rice
@ricejasonf
Nov 25 2015 23:05
#include<boost/hana.hpp>

namespace hana = boost::hana;

int main() {
  static_assert(hana::type_c<int> != hana::type_c<int&&>, "");
}
not the same apparently
Maik Klein
@MaikKlein
Nov 25 2015 23:08
yeah but I think
if you have f(int&& something);
the type of something might actually be just an int?
Jason Rice
@ricejasonf
Nov 25 2015 23:09
it just has to be an rvalue
I'm pretty fuzzy on that stuff btw ;)
Maik Klein
@MaikKlein
Nov 25 2015 23:11
template<class T>
void test1(T&& t){
  static_assert(hana::type_c<T> == hana::type_c<int>, "");
}
Jason Rice
@ricejasonf
Nov 25 2015 23:11
ooh
nice
Maik Klein
@MaikKlein
Nov 25 2015 23:11
calling it like test1(5);
Jason Rice
@ricejasonf
Nov 25 2015 23:12
in that case it can also be an lvalue
what happens then?
Maik Klein
@MaikKlein
Nov 25 2015 23:12
int& I guess
Jason Rice
@ricejasonf
Nov 25 2015 23:13
yeah
#include<boost/hana.hpp>

namespace hana = boost::hana;

template<class T>
void test1(T&&) {
  static_assert(hana::type_c<T> == hana::type_c<int>, "");
}

int main() {
  static_assert(hana::type_c<int> != hana::type_c<int&&>, "");
  test1(5);
  int x = 5;
  test1(x);
}
fails the last test
so your ht function was passing it as t an lvalue
Maik Klein
@MaikKlein
Nov 25 2015 23:16
yep
Jason Rice
@ricejasonf
Nov 25 2015 23:17
mind if I answer your question?
Maik Klein
@MaikKlein
Nov 25 2015 23:17
sure
I mean I don't mind :D
Jason Rice
@ricejasonf
Nov 25 2015 23:17
I'll try not to screw this up :P