These are chat archives for boostorg/hana

15th
Dec 2015
Jason Rice
@ricejasonf
Dec 15 2015 00:29
In the doc, the hana::partition benchmark graphic appears to suggest that mpl::vector outperforms hana::tuple. Is that right? :astonished:
Louis Dionne
@ldionne
Dec 15 2015 19:41
@ricejasonf It very much looks like it! It means there’s room for improvement.
Louis Dionne
@ldionne
Dec 15 2015 19:51
These cases where MPL outperforms Hana could probably be addressed with a dedicated container for types/integral constants, which brings us back to what I was saying about tuple_t and tuple_c.
Jason Rice
@ricejasonf
Dec 15 2015 19:55
ah!
before you look at #222, I want to go back and get rid of that decay and do it the way filter does.
Louis Dionne
@ldionne
Dec 15 2015 20:01
Sure, go ahead.
The PR looked good to me the last time I checked, though.
Jason Rice
@ricejasonf
Dec 15 2015 20:01
This message was deleted
This message was deleted
Jason Rice
@ricejasonf
Dec 15 2015 20:16
It appears broken for filter too if I use an lvalue for xs. (tuple_c is an lvalue right? :P)
because integral_constant<...> const& doesn't have a ::value
Louis Dionne
@ldionne
Dec 15 2015 20:17
Oh gosh
Jason Rice
@ricejasonf
Dec 15 2015 20:18
It only happens with hana::id because it just forwards the return value
Louis Dionne
@ldionne
Dec 15 2015 20:18
Yes, I know it’s not of such a huge practical importance, but it’s still annoying.
Jason Rice
@ricejasonf
Dec 15 2015 20:22
pretty high impact to go through and add decay all over the place. Is there a better way?
Jason Rice
@ricejasonf
Dec 15 2015 20:34
This is just spit balling...
struct Predicate
{
  template<typename X, typename F>
  constexpr bool operator()(X&& x, F const& f) const
  {
    return !decltype(hana::not_(f(static_cast<X&&>(f))))::value;
  }
}
then you could just say that a predicate is a function that returns a Logical
idk if that adds too much overhead though
Louis Dionne
@ldionne
Dec 15 2015 20:42
Predicates used to be required only to return Logicals, but I changed it for performance reasons.
Jason Rice
@ricejasonf
Dec 15 2015 20:42
ah
Louis Dionne
@ldionne
Dec 15 2015 20:43
Some predicates still only require a Logical, but I’d like to eventually clean this up.
Also, I generally find the Logical concept to be unsatisfying, and I’d like to get rid of it in the future.
Instead of Logical, I’d rather have something like a boolean algebra
Jason Rice
@ricejasonf
Dec 15 2015 20:45
interesting
if you want, I can add tests with lvalues to create explosions :boom:
Do you think we should just get rid of the "convertible to bool" and just say it has to be a compile-time bool?
Louis Dionne
@ldionne
Dec 15 2015 20:52
That’s a good question.

if you want, I can add tests with lvalues to create explosions

Yes, that would be nice.

Right now, I am inclined to think that we should allow predicates to return anything that can be converted to bool, as currently specified.
It’s more flexible, and also more consistent with the fact that an int is a Logical.
So it makes sense to say if(3, xxx, yyy).
Jason Rice
@ricejasonf
Dec 15 2015 23:05
Which is more favorable, using std::declval<Pred>() or having a Pred const& pred member? hana::partition uses the former and hana::filter the latter. I figure I could make them consistent while I'm at it, unless you object.
Those are the only two with that problem with the predicate returning a const& btw
Actually idk, it looks pretty deliberate. I'll refrain from changing it.