Currently, the PTE solver methods all assume there are only three (four if you include Real) types: 1) the EOS array type, 2) the Real array type, and 3) the lambda array type. The issue I'm encountering is that a common design pattern is to mix things like Kokkos views with Kokkos subviews. Although these behave the same (after I wrap them in a square bracket operator), they are different types that are not implicitly convertible.
I would request that we allow the PTE solver methods to have distinct template types for at least the arrays being passed. In a C++14 world without CTAD, I understand the desire to keep template parameter lists short, but now we can just deduce the types easily and I don't believe there's a real reason to limit the number of template parameters for a class.
So this change would also probably require (for usability) adding CTADs to the PTE solver methods.
As a bonus, I think there is a way to also achieve backwards compatibility if that is desired. Here is an example that ChatGPT came up with. Mind you it would involve a second layer of inheritance...
// primary declaration
template<class ObjArr, class... Ts>
class MyClass;
// 5-arg base implementation
template<class ObjArr, class Real1, class Real2, class Real3, class CacheArr>
class MyClass<ObjArr, Real1, Real2, Real3, CacheArr>
{
ObjArr& obj_arr_;
Real1& real1_;
Real2& real2_;
Real3& real3_;
CacheArr& cache_;
public:
MyClass(ObjArr& o, Real1& r1, Real2& r2, Real3& r3, CacheArr& c)
: obj_arr_(o), real1_(r1), real2_(r2), real3_(r3), cache_(c) {}
};
// 3-arg legacy spelling delegates to 5-arg via inheritance
template<class ObjArr, class Real, class CacheArr>
class MyClass<ObjArr, Real, CacheArr>
: public MyClass<ObjArr, Real, Real, Real, CacheArr>
{
using Base = MyClass<ObjArr, Real, Real, Real, CacheArr>;
public:
using Base::Base;
};
// CTAD
template<class ObjArr, class Real1, class Real2, class Real3, class CacheArr>
MyClass(ObjArr&, Real1&, Real2&, Real3&, CacheArr&)
-> MyClass<ObjArr, Real1, Real2, Real3, CacheArr>;
Tagging @jonahm-LANL @Yurlungur and @adamdempsey90
Currently, the PTE solver methods all assume there are only three (four if you include
Real) types: 1) the EOS array type, 2) the Real array type, and 3) the lambda array type. The issue I'm encountering is that a common design pattern is to mix things likeKokkosviews withKokkossubviews. Although these behave the same (after I wrap them in a square bracket operator), they are different types that are not implicitly convertible.I would request that we allow the PTE solver methods to have distinct template types for at least the arrays being passed. In a C++14 world without CTAD, I understand the desire to keep template parameter lists short, but now we can just deduce the types easily and I don't believe there's a real reason to limit the number of template parameters for a class.
So this change would also probably require (for usability) adding CTADs to the PTE solver methods.
As a bonus, I think there is a way to also achieve backwards compatibility if that is desired. Here is an example that ChatGPT came up with. Mind you it would involve a second layer of inheritance...
Tagging @jonahm-LANL @Yurlungur and @adamdempsey90