mdspan/mdarray template functions and utilities

[divyegala]

No description provided.

[ajschmidt8]

Removing ops-codeowners from the required reviews since it doesn't seem there are any file changes that we're responsible for. Feel free to add us back if necessary.

[divyegala]

I am not sure if these operators are needed anymore

[trivialfis]

Probably no, if you don't want implicit conversion.

[divyegala]

I propose that we give users two options here:

1. They directly implement array_interface
2. For users with existing owning types, we just ask that they add a view() method that returns a host_mdspan or device_mdspan or a derived type

Point 1 is already implemented, and point 2 allows users to update their existing their code minimally.

[divyegala]

Point 2 is solved with recent updates

[trivialfis]

If this function accepts (or will potentially accept in the future) an owning type, and might change the size of the underlying memory buffer, one might want to accept a raft handle as a parameter.

[divyegala]

I think we are going to be explicit about size changes with a different function called resize. Either way, wouldn't that have to be a member function to be able to access the underlying buffer?

[trivialfis]

I think it's the best to avoid override and use curiously recurring template pattern:

template <Base>
class array_interface : public Base {
    auto view() { return Base::view(); }
}

class mdarray : public array_interface<mdarray> {}

[divyegala]

Sounds good, this looks clean.

[divyegala]

This looks a little difficult to implement for my template checks though. Right now I check at compile-time if my object can be converted to a pointer of type array_interface (mdarray being its derived type). I'm not sure how this will be checked with this new pattern. Unless the recursion means that it still works?

[trivialfis]

Hmm .. why do you need to make that check? If you want to emit error early, you can use:

template <typename ArrayInterface, typename std::enable_if_t<is_mdspan_v<decltype(std::declval<ArrayInterface>().view())>* = nullptr>
auto my_func(ArrayInterface const& arr) {
}

[trivialfis]

Having said that, I'm just trying to avoid c++ virtual table. Might not be the most rational choice but from my experience template is easier to handle than virtual functions.

[trivialfis]

Alternatively, std::is_convertible might help.

[divyegala]

std:is_convertible does not help since mdarray is a class-template and we do not know ahead of time if a template-type T could possibly be a class-template of mdarray. I like your solution though, we can check if the view() returns a type which satisfies is_mdspan_v

[wphicks]

Include stddef.h for size_t or include cstddef and use std::size_t where possible

[cjnolet]

We were largely discussing these designs throughout your progress on this PR and I don't see anything particularly concerning. LGTM

[divyegala]

rerun tests

[cjnolet]

@gpucibot merge