isInputRange is false for non-copyable types

[Dmitry Olshansky]

On Sunday, 15 April 2018 at 10:39:32 UTC, Jonathan M Davis wrote:
> On Sunday, April 15, 2018 10:14:20 Dmitry Olshansky via 
> Digitalmars-d 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.
>>
>> Input range should “produce” elements not keep cache of them, 
>> forward ranges may cache current item alright.
>
> If that were the route that we were going to go, then front and 
> popFront wouldn't make any sense at all. Rather, you'd treat it 
> more like in iterator in Java and have next() return the next 
> element and pop it off at the same time.

Surprisingly, they might have got that right.

> But even if we did that, it wouldn't have been appropriate in 
> the general case to move the element unless we put serious 
> restrictions on what could be an input range (e.g. that would 
> make no sense whatsoever with dynamic arrays or any kind of 
> container).

There it would copy. You get rvalue either way. Another option is 
ref scope T. I do not see incompatibility you seem to imply.


> So, while I'd love to have the opportunity to sit down and 
> redesign the range API, I don't see how we really can - not and 
> actually have it implemented as part of the language or Phobos 
> anyway.

Yeah, I think as surely as we can redesign postblit. Let’s not 
focus on learned helplessnes and “it’s just the way things are”. 
Recent opMove shows there is great flexibility in what can be 
done.

Seriously, it’s just fixing a library design issue even if its 
use proved viral.

>
> - Jonathan M Davis