I should probably have a sort prove it's not using the default predicate.
What do you mean?
Would using 'tuple_c' in all of that be okay?
It would, but I'd rather you leave it like it is, since
tuple_c might go at some point. Since it's already written with
make_tuple, there's little benefit to removing it.
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).