Range documentation

[Jonathan M Davis]

On Sunday, March 24, 2013 12:14:56 deadalnix wrote:
> Sure we are stuck, because fixing this would require a refinement
> of the range concept, and it is kind of too late for that.
> 
> But you say that this inherently impossible without actually
> providing anything convincing in that direction. I don't think it
> is, I just think that as usual as hoc solutions are conglomerated
> in what is now ranges.

It's inherently impossible because the only way for it to be possible is to 
make it so that all ranges are reference types or so that all ranges are value 
types (that's the only way that copying them will always have the same 
semantics), and it's not possible for all ranges to be reference types or for 
all ranges to be value types. The very nature of a pure input range makes it a 
reference type, so we couldn't make all ranges value types, and the fact that 
arrays are always sliced when you pass them to a function makes it so that 
they can't be reference types. So, you can't make it so that all ranges are 
one or the other, and so you can't guarantee that copying them will always 
have the same behavior. Either we'd have to ditch pure input ranges (which 
actually wouldn't hurt my feelings any) or fundamentally change how arrays 
work (which probably be a bad idea) in order to make it so that all ranges are 
value types or so that all ranges are reference types. But the basic design of 
ranges precludes making it so that they're all one or the other.

- Jonathan M Davis