Proposal: takeFront and takeBack

[Jonathan M Davis]

On Wednesday, July 04, 2012 10:20:58 Mehrdad wrote:
> On Wednesday, 4 July 2012 at 08:18:35 UTC, Mehrdad wrote:
> > On Wednesday, 4 July 2012 at 08:16:32 UTC, Roman D. Boiko wrote:
> >> On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
> >>> What's wrong with moveFront()?
> >> 
> >> It has different semantics. For example, it is only supported
> >> for ranges which have movable elements. After moveFront, the
> >> element which was placed in the front position is replaced by
> >> E.init (E is element type).
> > 
> > WHOA I did not know that.
> > 
> > I just thought it was front() + popFront()...
> > 
> > In that case I think we _really_ need to get the naming right
> > (consume is horrible, IMO -- very unintuitive) to avoid
> > confusion....
> 
> I propose we just allow (but not require) popFront() to return
> ElementType!(R) instead of void?
> 
> That way, people who need the performance can check to see the
> return type, and use it without front() if needed.

That would mean that every time you popped an element from a range when you 
didn't actually need to see it (e.g. popFrontN) would incur additional cost. 
It's very much on purpose that the function for popping front and the function 
for accessing it are not the same by default. It's inefficient in many cases.

The problem is that it can also be inefficient to have them separate in some 
cases (much rarer cases though, since most ranges don't have to repeat 
calculations between front and popFront like happens with strings). So, by 
adding consumeFront, we have the possibility of doing both.

Also, ranges like ByLine _can't_ have popFront return front, since it was just 
invalidated by popFront. And if you have to check whether popFront returns or 
not, how does that save you anything over checking hasConsume?

- Jonathan M Davis