isInputRange is false for non-copyable types

[Dmitry Olshansky]

On Tuesday, 17 April 2018 at 15:14:02 UTC, Steven Schveighoffer 
wrote:
> 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.
>

For many algorithms indeed you can’t stop w/o peeking ahead. It’s 
just that lookahead of 1 is hardcoded in the range definition b/c 
it’s enough for a lot of things.

But then once you are past lookahead of 1, it has to do .save + 
restore if overshot. ungetc of 2 if you’d like.

> 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).

Might be an option. But as long as you have front/popFront/empty 
as well, no concurrent stuff.

> 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

File caches, byLine actually does
“read up until EOL and give me slice of that”

I do not see where caching of char[] plays any significant role. 
Except that due to how ranges work it likely has to do the 
readline at _empty_ or on construction + popFront.

> 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