protocol for using InputRanges

[Steven Schveighoffer]

On Thu, 27 Mar 2014 17:28:05 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 3/27/2014 1:59 PM, Steven Schveighoffer wrote:
>> On Thu, 27 Mar 2014 16:53:35 -0400, Walter Bright  
>> <newshound2 at digitalmars.com>
>> wrote:
>>
>>> On 3/27/2014 9:12 AM, monarch_dodra wrote:
>>>> If you initialized the next element in both constructor
>>>
>>> As mentioned earlier, requiring this of a range constructor makes it
>>> impossible to separate composition of a range with using it.
>>
>> Not impossible. Use lazy initialization.
>
> That still doesn't work, because then you could be calling front, and  
> front might fail if there's no input.

In the cases where you know there is input, that's not true. What I am  
protesting is the idea that you *know* input exists, you must still call  
empty. Front is enough in that case.

> What is wrong with following the protocol? Why must we introduce all  
> these caveats for ranges, like streams not working, front that can fail,  
> can't do C# style LINQ, etc.? For what gain?

There is no gain to requiring empty on ranges where you logically prove  
they are not empty. It's a wasted call. For things where you're not sure  
if they are empty or not (e.g. an input file), of course empty is required  
to be called, and of course it may do some processing to determine that.  
But I would only expect that on the first call. Subsequent checks would  
already be done by popFront.

>> It only makes sense if you are using empty in your processing of the  
>> range.
>
> I.e. follow the danged protocol and it works.

I mean, if you are calling empty regularly, because you aren't sure  
whether the elements are there. That's not always the case, sometimes you  
are sure the elements are there. Requiring a call to empty to do anything  
other than to check whether a range is empty, is just plain wrong. I'm  
sure there's better ways to implement what you want without stitching the  
functionality onto empty.

-Steve