Range documentation

[deadalnix]

On Sunday, 24 March 2013 at 09:36:34 UTC, Jonathan M Davis wrote:
> 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.
>

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.