Daniel Frey <daniel.frey@aixigo.de> writes:
David Abrahams wrote:
Daniel Frey <daniel.frey@aixigo.de> writes:
I don't see any need to extend the legal use of next/prior to anything else than iterators. It was already legal for non-iterators. What made you think otherwise?
The documentation and the way I was reading it :)
as the documentation only speaks about iterators and never bothers to mention non-iterators. Thus, the bug is IMHO that it's not explicitly documented that next/prior's first argument must meet the interator requirements. Sorry, dude, I get final say on original intent, since it was mine.
Of course, but what's wrong with mentioning non-iterators explicitly?
Nothing's wrong with it; I just didn't happen to.
Or more generally writing down the requirements then?
The requirements are clearly implied by the specification of the function. This one is so simple that it's best to just show how it's implemented.
IIUC, you think that next/prior should work for all types that provide ++ and --, plus using + and - in cases where it's faster, right? (constant time complexity when possible, linear otherwise).
That would be best.
Iterators being only one example of types that fulfill these requirements.
Providing the implementation for next/prior in the documentation might be sufficient for the one-argument-version, but for the two argument version it's quite hard to help getting the implementation bug-free if I don't know what you intended. Can you write down original intent, please?
Well, you came up with the 2-arg version. I can only say that the original intent of the 1-arg versions was to operate on anything supporting prefix ++/--, respectively. If the 2-arg version won't do that, I guess we should change the name. Incidentally, it's almost always possible to detect whether the first argument supports operator += or operator-=. That might be a good way to decide whether to advance/regress it. -- Dave Abrahams Boost Consulting www.boost-consulting.com