Range of uncopyable elements

[Jerry via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 17:29:42 UTC, H. S. Teoh wrote:
> The problem is that most range algorithms won't work if `auto h 
> = r.front;` doesn't compile.  Random chunks of std.algorithm 
> won't work for such a range.
>
> One may argue, of course, that std.algorithm ought to be 
> fixed... but the root of the problem really is a conceptual 
> one. The definition of a range was made as an extension of a 
> C++ iterator, which is basically a wrapped pointer. So `auto h 
> = r.front;` is assumed to be a cheap copy of a *reference* to 
> the underlying data, rather than copying the data itself. This 
> is why most of std.algorithm is written the way it is, and why 
> isInputRange is defined the way it is.  A range of non-copyable 
> elements in this sense is a poor fit for the range concept; a 
> better fit would be a range of references to an underlying 
> container of non-copyable elements. Hence my suggestion of 
> using pointers.
>
> (In any case, conflating a range with a container is usually a 
> red flag that there's a conceptual mismatch somewhere. 
> Unfortunately built-in arrays aren't helping by hiding the fact 
> that the container is actually GC-managed memory, which isn't 
> directly visible to the user, thus perpetuating the 
> misconception that range == container.)
>
>
> T

Well it's exactly like that for C++ as well. std::copy(Iter, ...) 
won't compile if the values aren't copyable. There's no 
constraints in C++ either so you get some cryptic error message. 
The entire std library is like that.

Assuming that is wrong though, as you aren't copying an iterator 
or range you are copying the actual value. What you are confusing 
"auto h = r.front;" for is this: "auto rcopy = r;". The D code 
"auto h = r.front" is not a cheap operation and the equivalent in 
C++ is actually this: "auto h = *iterator;" and one should not 
assume it is cheap, cause it isn't. Anyways your comparison with 
C++ is off.