These are chat archives for boostorg/hana

13th
Dec 2015
Jason Rice
@ricejasonf
Dec 13 2015 09:44
hana::plus.by(1)
Louis Dionne
@ldionne
Dec 13 2015 17:49
@ricejasonf That looks good for a test case!
Jason Rice
@ricejasonf
Dec 13 2015 18:24
I should probably have a sort prove it's not using the default predicate.
Would using 'tuple_c' in all of that be okay?
Louis Dionne
@ldionne
Dec 13 2015 18:45

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.

Louis Dionne
@ldionne
Dec 13 2015 19:05
@ricejasonf I just saw that you were using tuple_c in some places. I don’t care, just do as you please.
Jason Rice
@ricejasonf
Dec 13 2015 21:07
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.
@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?
Louis Dionne
@ldionne
Dec 13 2015 22:17

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_c and 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.

Jason Rice
@ricejasonf
Dec 13 2015 22:22
ah
Louis Dionne
@ldionne
Dec 13 2015 22:23
But I do agree that keeping a terse way to construct sequences of types and sequences of integral constants is useful. I won’t take this away without a seriously good reason.