Proposal: takeFront and takeBack

[Jonathan M Davis]

On Wednesday, July 04, 2012 10:37:41 Mehrdad wrote:
> On Wednesday, 4 July 2012 at 08:35:30 UTC, Dmitry Olshansky wrote:
> > On 04-Jul-12 12:29, Mehrdad wrote:
> >> On Wednesday, 4 July 2012 at 08:25:59 UTC, Roman D. Boiko
> >> 
> >> wrote:
> >>> That would be almost perfect. But has drawbacks:
> >>> 
> >>> * if element is big and may be not needed in all calls to
> >>> popFront
> >>> (when the user wants to ignore elements), there would be some
> >>> overhead;
> >> 
> >> Could you give an example of such a range? Does such a
> >> heavyweight range
> >> come up in practice? (I'm assuming RVO would take care of not
> >> calling
> >> copy constructors and such.)
> > 
> > UTF strings - calculating length of codepoint is cheaper then
> > actually decoding it and then throwing away.
> 
> No, I think you misunderstood my question. I definitely know the
> use case for /that/.
> I was talking about an example of what I replied to, i.e. where
> Roman said the "element is big". dchars aren't big.

No, but if popFront on strings returned a dchar, popFront would be more 
expensive, because it would have to actually decode the code point rather than 
just find the next one.

As for elements being big, if you created a struct with dozens of fields, many 
of which were structs themselves, you'd definitely be incurring extra cost 
every time that an element was returned needlessly. Having really large 
structs like that is probably rare in ranges though, precisely because copying 
them would be expensive. They'd probably be made reference types instead. But 
still, having popFront return an element when it doesn't need to does incur a 
cost, regardless of the type returned, and since popFront is used for 
iteration, it'll happen in a loop pretty much by definition, which will 
increase that cost.

Having popFront return an element is a _bad_ idea IMHO. Ideally, it would be 
possible to either get front separately from popping an element and to get it 
when popping an element, rather than restricting it to one or the other. 
Adding consumeFront would make it possible to have both in the cases where it 
actually mattered.

- Jonathan M Davis