Update range() for additional features in python's range

[ryanhaining]

Give a range object r

• r.start(), r.stop(), and r.stop() constexpr member functions to match the .start, .stop, and .step properties.
• r.size() and r.length() to match len(r)
• r[index]

[MatthewSteel]

Would it be against the philosophy of this project to extend range iterators with the operations required of random access iterators? (operator+, operator< etc)?

It would be nice to get log time std::lower_bound with this library, and it's technically feasible. I can send a PR if it would be welcome.

[ryanhaining]

There are aspects of random access iterators that can't be easily handled by range, since there isn't an underlying sequence to point to. Even having it as a ForwardIterator is sort of lying. This is not to say that you couldn't go about implementing some of the operators, but standard libraries will still use the iterator category to figure it out, and you can't update the category without implementing all of the required functions.

Look at libc++'s implementation of std::lower_bound which calls through to std::advance, which of course is implemented using tag dispatch on the iterator_category.

I've thought about reaching for more advanced iterator tags before with range, I think bidirectional is doable, but the situation is more complicated with random access.

All that said, if you would like to look for a path forward I'm happy to talk or review PRs.

[MatthewSteel]

Hmm, I think the only real difficulty (though it may be insurmountable) is that the dereference operations are meant to return references, not values. All of the other operations look pretty simple.

Subclassing the trait tag with that imperfection is probably a dreadful idea, though, so I'll go another few years without a lightweight, well-maintained way to binary search over integers :-/.

Thanks for the help finding the flaw in that plan.

[ryanhaining]

Is there a std::ranges solution that you're alluding to coming in a few years?

…

On Sun, Jul 21, 2019, 5:31 PM Matthew Steel ***@***.***> wrote: Hmm, I think the only real difficulty (though it may be insurmountable) is that the dereference operations are meant to return references, not values. All of the other operations look pretty simple. Subclassing the trait tag with that imperfection is probably a dreadful idea, though, so I'll go another few years without a lightweight way to binary search over integers :-/. Thanks for the help finding the flaw in that plan. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#55?email_source=notifications&email_token=AAIWWWNWWJPOYYOJQPPFWPTQAT5WTA5CNFSM4HARYGNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2OPA2A#issuecomment-513601640>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIWWWMH2MTCQXEDMLBVGJTQAT5WTANCNFSM4HARYGNA> .

[MatthewSteel]

I wouldnt know sorry, I was just voicing a vague hope that enough people will reinvent the wheel that one of them will turn out to be useful.