On Sun, 23 Mar 2014 05:34:26 -0400, Szymon Gatner <noem...@gmail.com>
wrote:
On Sunday, 23 March 2014 at 00:50:34 UTC, Walter Bright wrote:
1. If you know the range is not empty, is it allowed to call r.front
without calling r.empty first?
IMO: yes. Logic of empty() sould be const and not have side effects.
Here is the crux of the issue. I think aside from Walter's question, we
have situations where it is expensive to construct each value of a range.
For a range that is never used, that is an expense that you don't have to
pay.
There was a post a little while ago about how File.byLine reads the first
line on construction. Consider the case where stdin.byLine needs to be
constructed, but not *iterated* before writing some information to stdout.
This gives us a predicament that the first line has to be available before
you can output any instructions. As we all know, stdin will block on first
read, unless you piped in a file or something. This makes an interactive
program simply incorrect.
From the library point of view, caching the first line on construction is
the most sensible thing -- This allows empty, front, and popFront to all
be consistent across the entire iteration. Making empty or front do
something different on the first access requires awkward machinery (a
boolean indicating it should do so, plus a check every call thereafter).
But from the user's point of view, sometimes you want lazy access to the
first element, for logical reasons.
I think in light of such possibilities, empty and front should not have to
be const or pure. Logically, it can be viewed that way, but not
technically.
-Steve
