range behaviour

[Jonathan M Davis via Digitalmars-d]

On Tue, 13 May 2014 13:29:32 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d at puremagic.com>
wrote:

> On Tue, 13 May 2014 12:58:09 -0400, Jonathan M Davis via
> Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
> > On Tue, 13 May 2014 18:38:44 +0200
> > Benjamin Thaut via Digitalmars-d <digitalmars-d at puremagic.com>
> > wrote:
> >
> >> I know that there was a recent discussion about how the methods of
> >> ranges should behave.
> >>
> >> E.g.
> >>
> >> - Does empty always have to be called before calling front or
> >> popFront?
> >
> > Certainly, ranges are pretty much always used this way, but there
> > was some
> > debate as to whether empty could have work done in it (and thus
> > _had_ to be
> > called). However, I believe that the consensus was that yes, empty
> > had to be
> > called (certainly, both Walter and Andrei felt that way).
>
> I don't agree there was a consensus. I think empty should not have to
> be called if it's already logically known that the range is not
> empty. The current documentation states that, and I don't think there
> was an agreement that we should change it, despite the arguments from
> Walter.
>
> In any case, I think generic code for an unknown range type in an
> unknown condition should have to call empty, since it cannot
> logically prove that it's not.
>
> Even if it was required, it would be an unenforceable policy, just
> like range.save.

Yeah, and they're both cases where the common case will work just fine if you
do it wrong but which will break in less common cases, meaning that the odds
are much higher that the bug won't be caught. :(

- Jonathan M Davis