protocol for using InputRanges

[Regan Heath]

On Thu, 27 Mar 2014 10:49:42 -0000, Marc Schütz <schuetzm at 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/