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.
