isInputRange is false for non-copyable types

[Steven Schveighoffer]

On 4/15/18 6:14 AM, Dmitry Olshansky wrote:
> On Sunday, 15 April 2018 at 06:39:43 UTC, Jonathan M Davis wrote:
>> On Sunday, April 15, 2018 07:26:54 Shachar Shemesh via Digitalmars-d 
>> wrote:
>>> [...]
>>
>> It's extremely common for range-based functions to copy front. Even 
>> foreach does it. e.g.
>>
>> [...]
> 
> 
> Arguably it should “move” them.
> 
> This would have worked if input ranges didn’t have to cache front to 
> support multiple ‘front’ calls before popFront. Which is a painful 
> misfeature really as all algorithms would optimize for touching front 
> once anyway.

Ugh, then you get things like fungetc.

However, there are certainly cases where it's expensive to compute 
front, and therefore, requires a cache. A new primitive that accesses 
front and pops it at the same time would be useful. We can have selected 
algorithms that can deal with it use that primitive instead (and 
instrument foreach to do it). Potentially, we can create a wrapper for 
all input ranges such that they support it.

> Input range should “produce” elements not keep cache of them, forward 
> ranges may cache current item alright.

Well, sometimes you HAVE to cache it. For instance File.byLine is 
clearly an input range, and not a forward range. But it MUST cache 
because it's i/o that has to be buffered to be looked at! No reason to 
force caching on the user at that point.

-Steve