On Thu, 27 Mar 2014 11:19:15 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 3/27/14, 3:49 AM, "Marc Schütz" <schue...@gmx.net>" wrote:
I was originally going to do that, but then I took a closer look at the
documentation, which says ([1] in the documentation of
`isInputRange()`):
"Calling r.front is allowed only if calling r.empty has, or would have,
returned false."
Probably we need to amend that. For efficient ranges, front() and
popFront() should only be guaranteed to work if either empty() or
length() were evaluated first, and they returned false or nonzero,
respectively.
This is a misleading statement. An array is probably the most efficient of
ranges, which does not require this.
We should be more specific here. For certain types of *nonempty* ranges,
front is only guaranteed to work if empty/length was called before front
is called. I would not necessarily lump popFront into that requirement
automatically, popFront may be able to cope with not having cached the
first element without losing efficiency.
Questions to answer:
1. What types of ranges does this rule apply to?
2. What is the cost of not requiring this in terms of efficiency and ease
of implementation.
3. Is there a better mechanism to use than misusing empty? should we
introduce another property/call?
At the moment, the only candidates I can think of are lazy caching ranges.
How many of those exist?
-Steve
