Simplify using APIv1 through APIv2 interface

[aprokop]

Right now, it is inconvenient to get the old behavior. One has to write

ArborX::BVH<MemorySpace, ArborX::PairValueIndex<Box>>
  tree(space, ArborX::Experimental::attach_indices(boxes));
tree.query(space, queries, ArborX::LegacyDefaultCallback{}, indices, offsets);

The presence of the LegacyDefaultCallback is really annoying.

This patch changes this. It automatically adds LegacyDefaultCallback
if the following 3 conditions are satisfied:

1. A user does not provide a callback
2. The index is constructed on PairValueIndex
3. The output value_type matches the index_type in the PairValueIndex.

[aprokop]

@dalg24 Thoughts?

[dalg24]

Did you try to deduce the integral type to use instead of only enabling for unsigned

[aprokop]

Did you try to deduce the integral type to use instead of only enabling for unsigned

I didn't enable it only for unsigned. I enabled it for the case where the index type stored in PairValueIndex matches the view's value_type provided by the user. Could be both unsigned or int. I decided not to do any implicit conversions.

As the user is the one in control for both types, we cannot do anything on our side imho.

[dalg24]

Exactly I was thinking about doing the conversion. Why do you think we shouldn't?

[aprokop]

Exactly I was thinking about doing the conversion. Why do you think we shouldn't?

I am concerned about losing precision. What if the hierarchy is created on PairValueIndex<Geometry, unsigned> and user requested Kokkos::View<short*>?

Converting unsigned -> int is maybe ok. It would be nice to make user to explicitly allow enable conversion.

[dalg24]

We say that all attached indexes being representable as the integral value type of the view is a precondition

[aprokop]

We say that all attached indexes being representable as the integral value type of the view is a precondition

You mean in the documentation? This feels like prone to subtle errors.
And still won't solve (unsigned, int) pair. Unless you are talking about actually stored values and not the ranges.

Could theoretically use something like std::in_range (I know, C++20) for individual values careful conversion. Not sure about the performance cost.

[aprokop]

After a discussion, we agreed to relax the requirements on type matching, and simply require that the value type in the output view is integral.

Rationale: we already do if for the query(space, predicates, indices, output) in the legacy format, and the output time does not have to match.