On Thu, 27 Mar 2014 10:49:42 -0000, Marc Schütz <schue...@gmx.net> wrote:
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
That's because up until now we've made no attempt to set this in stone,
and as such many interpretations have surfaced. This documentation would,
of course, change to match the final decision made.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
