add new range constructors #1295
Conversation
| * \return a newly constructed TypedRangeSegment where the | ||
| * value_type is equivilent to the common type of | ||
| * @begin and @end. If there is no common type, then | ||
| * a compiler error will be produced. |
|
Do you want to support making ranges from iterators too? |
|
Probably yes, I imagine we'll want a convenient way to get TypedListSegment and span instances, maybe even IndexSets. This is kinda step one to feel out how we'd want the interface to look, do you have a specific iterator use-case in mind? |
|
I was thinking of taking pointer and length or pointer and pointer and producing spans. |
|
I don't think we can do TypedListSegment if it still requires a resource. |
|
We had recent discussions of making ListSegment un-owned only, which come to think of it would basically just make it a span wouldn't it? That's an interesting thought, maybe we should reconsider our naming and taxonomy a bit while we're at it. |
include/RAJA/index/RangeSegment.hpp
Outdated
| template<typename Idx> | ||
| ::RAJA::TypedRangeSegment<Idx> range(Idx start, Idx end, Idx stride) | ||
| { | ||
| return ::RAJA::TypedRangeStrideSegment<Idx>( |
|
Looking more closely at the Segment implementations, RangeSegment is basically the same as Span, it holds two iterators. RangeStrideSegment is similar, it also holds size so division is only done at construction. Should we consider condensing the implementation of the RangeSegments and Span into one type? In another PR. |
|
@MrBurmark I think that is the sort of thing we want to decide. IMO, condensing the types and implementations is good. We want to end up with something that is clear and intuitive for users. |
|
In the end, we probably want them all to be "ranges", and "views" in the c++20 sense, which means a combination of an iterator and a sentinel, and in the case of a view it also means that move or copy construction is O(1). In principle the numeric ranges are the same as a span over an iterator, rather than a pointer. They could be the same thing as long as we keep the check logic in a creation function. |
trws
force-pushed
the
scogland1/feature/range-ergonomics
branch
from
a9bc401 to
de633a0
Compare
This is a draft of new range ergonomics. I did it for now as new overloads of
make_rangebecause we already have that, but I'm tempted to do something else with naming. The first of these was my original thought, but each has some benefits:RAJA::range([start,]end[,stride])list()or similar as another optionThe big win here is that good old type inference and argument counts will give us well formed
TypedRangeSegmentandTypedRangeStrideSegmentas appropriate with a short, rather pythonic, syntax. Trick is how to make it all fit in.