On Thursday, 27 March 2014 at 04:17:16 UTC, Walter Bright wrote:
On 3/26/2014 7:55 PM, Steven Schveighoffer wrote:
OK, but it's logical to assume you *can* avoid a call to empty
if you know
what's going on under the hood, no? Then at that point, you
have lost the
requirement -- people will avoid calling empty because they
can get away with
it, and then altering the under-the-hood requirements cause
code breakage later.
Case in point, the pull request I referenced, the author
originally tried to
just use empty to lazily initialize filter, but it failed due
to existing code
in phobos that did not call empty on filtered data before
processing. He had to
instrument all 3 calls.
As with *any* API, if you look under the hood and make
assumptions about the behavior based on a particular
implementation, assumptions that are not part of the API, the
risk of breakage inevitably follows.
If you've identified Phobos code that uses ranges but does not
follow the protocol, the Phobos code is broken - please file a
bugzilla issue on it.
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."
(And the same for `popFront()`.)
That is, the documentation more or less explicitly states that
you don't actually need to call `empty` if you know it returned
`true`.
[1] http://dlang.org/phobos/std_range.html
