protocol for using InputRanges

[Marc Schütz" <schuetzm at gmx.net>]

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