Range documentation

[Jonathan M Davis]

On Sunday, March 24, 2013 09:42:28 deadalnix wrote:
> For instance, passing a range by value is unspecified.

And it never will be specified, because it's range-dependent and can't ever be 
anything but range-dependent. That's why save was introduced in the first 
place. If you want to guarantee that a range is consumed, you make sure that 
the range-based function that you're passing the range to takes it by ref. If 
you want to guarantee that it's not consumed, then you call save and pass its 
result to the range-based function. Beyond that, you have to write your code 
in a way in which it doesn't matter whether the range is consumed or not when 
it's passed to a function, because that depends on the type of the range.

There's literally no technical way to avoid this except for

1. Require that all range-based functions take ranges by ref, which is not 
only unenforceable but would kill function chaining, which is one of the great 
strengths of ranges.

2. Require that all ranges be reference types, which again, is not 
enforceable, but also wouldn't work with ranges, because they're always sliced 
when you pass them to a function (and you couldn't require that all ranges be 
value types, because pure input ranges can never be value types).

So, we're stuck. Sure, the fact that whether a range is consumed or not when 
passed to a function is effectively undefined is troublesome, but there's really 
no way around it.

- Jonathan M Davis