On Friday, 22 January 2016 at 11:23:05 UTC, Jonathan M Davis wrote:
> Arguably, walkLength shouldn't even accept a range that isn't a forward range, since if it's not, then walkLength is just going to eat the range. As for calling save, there's no point. It's too late as soon as you've passed the range into the function, since that copied the range, which is undefined behavior due to the fact that the exact semantics of copying a range vary wildly depending on how a range is implemented. In generic code, if you want to use a range after passing it to a function, you have to call save and pass that to the function; otherwise, you get undefined behavior when you do anything with the range after passing it to the function.

Yes actually this was my point, why not forcing the range to be a forward range? The only advantage I see is that it allows to count the number of elements of an input range, but then I guess it would need to be mentioned in the documentation somewhere, what do you think?

Yes my code is wrong sorry about that, I was just trying to figure out how to force the saving in some way...

And coming back to the specialized version of walkLength: in the case where joiner does not implement save, should I still allow the specialized version? (and in this case do what: consume the range, make a copy of "this" and hope for the best, something else?)

Maverick Chardet

On 01/22/2016 07:59 AM, Maverick Chardet wrote:
> And coming back to the specialized version of walkLength: in the case
> where joiner does not implement save, should I still allow the
> specialized version? (and in this case do what: consume the range, make
> a copy of "this" and hope for the best, something else?)
>
> Maverick Chardet

walkLength is what walkLength does: it accepts even an input range and has the discretion to consume it. So let them eat cake. -- Andrei