Remove PrimitivesTag and PredicatesTag

[aprokop]

• Remove PrimitivesTag and PredicatesTag
• Update check_valid_access_traits and provide CheckReturnTypeTag for predicates
• Fix all examples, tests and benchmarks
• Beef up access traits testing

Newer version of #997. Don't know if we want to rename AccessTraits to RangeTraits.

[aprokop]

Rebased to resolve conflicts.

[aprokop]

Rebased to resolve conflicts.

[dalg24]

Would you remind me whether we considered introducing a newer traits (not just a rename) and have the old access traits automatically translated to it if no specialization is provided?

[dalg24]

Suggested change

	KOKKOS_FUNCTION static auto get(Self const &self, int i)
	KOKKOS_FUNCTION static auto get(Self const &self, Index i)

And Index(i) -> I below in both branches of the if constexpr

[aprokop]

This breaks custom index test in tstCompileOnlyAccessTraits.cpp, as we can't call Access::get(values, CustomIndex).

[dalg24]

I would potentially want us to revisit but it does not need to be done right now

[aprokop]

Would you remind me whether we considered introducing a newer traits (not just a rename) and have the old access traits automatically translated to it if no specialization is provided?

I don't think so.

[dalg24]

Would you remind me whether we considered introducing a newer traits (not just a rename) and have the old access traits automatically translated to it if no specialization is provided?

I don't think so.

What are your thoughts about it? I expect that is implementable and may be nice to have but I lost track of all the changes and maybe that's just overkill.

[aprokop]

What are your thoughts about it? I expect that is implementable and may be nice to have but I lost track of all the changes and maybe that's just overkill.

Just so that I understand, you are talking about introducing something like RangeTraits that would not have tags, using it internally, and providing specialization that would take tagged AccessTraits? I don't quite understand what you mean by "have the old access traits automatically translated to it if no specialization is provided".

[dalg24]

Just so that I understand, you are talking about introducing something like RangeTraits that would not have tags, using it internally, and providing specialization that would take tagged AccessTraits?

Yes pretty much

I don't quite understand what you mean by "have the old access traits automatically translated to it if no specialization is provided".

What you said above, "providing specialization that would take tagged AccessTraits"

[aprokop]

Yes pretty much

I can try to implement this. So, we would advertise new traits (RangeTraits?) but users won't have to rewrite the existing ones? Wonder how much benefit there is, as we already broke backwards compatibility in the indexes constructors. We would need to do a bunch of renaming, too, from AccessValues to RangeValues and similar.

[dalg24]

I can try to implement this. So, we would advertise new traits (RangeTraits?) but users won't have to rewrite the existing ones?

Correct

Wonder how much benefit there is, as we already broke backwards compatibility in the indexes constructors.

That was my question

[aprokop]

Wonder how much benefit there is, as we already broke backwards compatibility in the indexes constructors.

That was my question

I see little. I'd rather have users to go through upgrade once, with the major version release. In addition, I think it would give users a chance to reexamine their AccessTraits structures to see what they actually need to return now that they are not limited to points and boxes.

I do want to decide what we should call the traits. Doesn't have to be done here, though.

[dalg24]

Fine with renaming later