On Wed, 26 Mar 2014 13:36:08 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 3/26/14, 8:37 AM, Steven Schveighoffer 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.
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.
I think requiring users to call empty before front on input ranges is a
concession we should make.
if(!r.empty)
{
auto r2 = map!(x => x * 2)(r);
do
{
auto x = r2.front;
...
} while(!r2.empty);
}
Should we be required to re-verify that r2 is not empty before using it?
It clearly is not, and would be an artificial requirement (one that map
likely would not enforce!).
This sounds so much like a convention that simply won't be followed, and
the result will be perfectly valid code.
-Steve
