tuple_tare really convenient and make for more concise, readable code, although I guess I can't see many practical use cases for
tuple_c. I did see it used sparingly in other tests, which is why I didn't completely avoid using it. I definitely hope you keep
I wanted to make sure that the tests on functions with a default predicate would not accidentally be using the default predicate because of some substitution failure, though that is certainly not the case with the current implementations.
You wanted to make sure that
hana::sort(sequence, pred) wouldn't use
hana::sort(sequence) if the former was invalid? Indeed, that is not the case; it will trigger a hard compile-time error instead.
@ldionne tuple_c and tuple_t are really convenient and make for more concise, readable code, although I guess I can't see many practical use cases for tuple_c. I did see it used sparingly in other tests, which is why I didn't completely avoid using it. I definitely hope you keep tuple_t and range_c though. Is it a performance issue?
Sort of. It would be possible to have something much more performant by using a different representation for
tuple_t than the representation of
hana::tuple. But I think it would be better to introduce a separate
hana::types sequence or something like that.
count_if, but I was just exploring different solutions
decayand do it the way
integral_constant<...> const&doesn't have a
Logicalconcept to be unsatisfying, and I’d like to get rid of it in the future.
Logical, I’d rather have something like a boolean algebra
if you want, I can add tests with lvalues to create explosions
Yes, that would be nice.
bool, as currently specified.
if(3, xxx, yyy).
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.
I have no preference. Off the top of my head, I can't think of a reason to use a
Pred const& member over
std::declval, except for the need to include
<utlity> to use
<utility> is already included everywhere anyway, so this isn't a strong reason.
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.
What looks deliberate? The usage of
Pred const& over
std::declval()? It probably just happened that way, because both algorithms were implemented at different times.