std.range.interfaces : InputRange moveFront

[Johan Engelen]

On Friday, 1 December 2017 at 18:33:09 UTC, Ali Çehreli wrote:
> On 12/01/2017 07:21 AM, Steven Schveighoffer wrote:
> > On 12/1/17 4:29 AM, Johan Engelen wrote:
>
> >> (Also, I would expect "popFront" to return the element
> popped, but it
> >> doesn't, OK...
> >
> > pop removes the front element, but if getting the front
> element is
> > expensive (say if it's a map with a complex lambda function),
> you don't
> > want to execute that just so you can return it to someone who
> doesn't
> > care. This is why front and popFront are separate.
>
> Yet, we're told that compilers are pretty good at eliminating 
> that unused copy especially for function templates where all 
> code is visible.

I assume that Steven means "copying the front element" when he 
wrote "getting the front element"? There is no need for a copy, 
because the element will be removed from the range, so we can 
move (whose cost only depends on the size of the element, 
internal pointers being disallowed by the language).
If it is expensive to actually get _to_ the front/back element 
(i.e. find its memory location), then having to do the operation 
twice is a disadvantage.

Ali: the compiler can only elide copying/moving of an unused 
return value when inlining the function. (the duty of making the 
return value move/copy is on the callee, not the caller)

Note that because front/back() and popFront/Back() are separate, 
a copy *is* needed when one wants to "pop an element off". Thus 
moveFront/Back() and popFront/Back() should be used. OK.
The fact that "pop" does something different from other 
programming languages is something important to remember when 
teaching people about D. And I think should be made clear in the 
documentation; let's add an example of how one is supposed to use 
all this in an efficient manner?

Back on topic: let's change the documentation of moveFront such 
that it is clear that it does _not_ reduce the number of elements 
in the range?

> So, even though exception safety is not a common topic of D 
> community, the real reason for why popFront() does not return 
> the element is for strong exception safety guarantee.

Interesting point. Argh why do we allow the user to throw in move?

> Regardless, separating front() from popFront() is preferable 
> due to cohesion: fewer responsibilities per function, 
> especially such low level ones.

This doesn't make much sense ;-)
popFrontN has more responsibility, and one gains better 
performance than simply calling popFront N times. It's similar 
here.

-Johan