On Wed, 26 Mar 2014 15:37:38 -0000, Steven Schveighoffer
<[email protected]> wrote:
On Wed, 26 Mar 2014 11:09:04 -0400, Regan Heath <[email protected]>
wrote:
On Wed, 26 Mar 2014 12:30:53 -0000, Steven Schveighoffer
<[email protected]> wrote:
Gah, I didn't cut out the right rules. I meant the two rules that
empty must be called before others. Those are not necessary.
I see. I was thinking we ought to make empty mandatory to give more
guaranteed structure for range implementors, so lazy initialisation can
be done in one place only, etc etc.
Yes, but when you know that empty is going to return false, there isn't
any logical reason to call it. It is an awkward requirement.
Sure, it's not required for some algorithms in some situations.
I had the same thinking as you, why pay for an extra check for all 3
calls? But there was already evidence that people were avoiding empty.
Sure, as above, makes perfect sense.
It seemed from this thread that there was some confusion about how ranges
should be written and used, and I thought it might help if the
requirements were more fixed, that's all.
If r.empty was mandatory then every range implementer would have a place
to lazily initialise, r.front would be simpler, r.popFront too. Basically
it would lower the bar for "good" range implementations.
We might just need better documentation tho.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
