protocol for using InputRanges

[Steven Schveighoffer]

On Thu, 27 Mar 2014 19:52:52 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 3/27/2014 2:46 PM, Steven Schveighoffer wrote:
>> What I am protesting is the idea that you *know* input exists, you must  
>> still call empty.
>> Front is enough in that case.
>
> You can't use that on generic code, because generic code cannot assume  
> that front will not fail.

There is a difference here that I want to establish.

First, I completely agree that for generic code, for when an unknown range  
is passed in, empty is required to be called to verify that front is valid.

Second, while I agree that empty should be required to verify front is  
valid on unknown ranges, it should not be required, when it is known that  
it's not empty.

What you are proposing is that we take advantage of the requirement for  
empty on unknown ranges to require it on known ones. I disagree, the code  
looks awkward and incorrect. When I know something is empty, calling empty  
again doesn't give me information. instead empty now becomes "is it empty,  
and if it needs priming, prime it." I'd rather see another primitive,  
since empty does not convey that message.

A counter proposal -- What if we create a global method in std.range  
called prime. prime(r) will call r.prime if it exists, otherwise calls  
r.empty, and ignores the result. Code that wants to work with "primable"  
ranges, can call that function, and it's harmless for normal ranges, but  
will allow primable ranges to fetch the first element.

I think penalizing all range-using code to force a non-functional empty  
call would 1. artificially invalidate lots of currently valid code and 2.  
look completely awkward in cases where it's not normally necessary.

-Steve