Closed henryiii closed 3 years ago
This seems to say that the default is to only be inclusive if both underflow and overflow is set:
But, when customized for Integer,
Then options() & option::underflow || options() & option::overflow
is true if either one is set. I think it should be options() & option::underflow && options() & option::overflow
, perhaps?
Right, looks like a bug, thank you for reporting.
It looks like I did this on purpose and not by mistake, though, hm. I should have left a comment.
PS: If you start with integer, and then try regular, sadly this compiles correctly: bh::axis::regular<double, bh::use_default, bh::axis::option::overflow_t> - but is obviously wrong - the options are in the metadata slot. Don't know if there's a way to protect or print a warning if this happens, as anything is supported for metadata.
Yes, a safer order would have been value_type, metadata, options, transform
for the template arguments, but I chose to put the transform as a second argument instead, which I thought is more user-friendly. I will try to add some static_assert to check the passed types. This will be much nicer with concepts in the future.
Edit: On closer inspection, I think there is nothing I can do here to avoid this. Since metadata is allowed to be anything, I cannot really catch this.
@henryiii Did this bug affect you downstream?
Compiling the following program:
Gives this result:
It seems
integer
axis with only one flow bin is still "inclusive", unlike Regular (and Variable, though not shown above). Is this expected?PS: If you start with integer, and then try regular, sadly this compiles correctly:
bh::axis::regular<double, bh::use_default, bh::axis::option::overflow_t>
- but is obviously wrong - the options are in the metadata slot. Don't know if there's a way to protect or print a warning if this happens, as anything is supported for metadata.