Proposal: takeFront and takeBack

[Jonathan M Davis]

On Wednesday, July 04, 2012 10:16:05 Mehrdad wrote:
> On Wednesday, 4 July 2012 at 08:14:54 UTC, Jonathan M Davis wrote:
> > On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
> >> On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis
> >> 
> >> wrote:
> >> > If no one has any major objections to this scheme or can
> >> > provide a better proposal, I'll create a pull request from
> >> > what
> >> > I have.
> >> 
> >> No objections.
> >> 
> >> Still would be nice to get your (or community) feedback on my
> >> previous proposals to localize custom logic inside ranges which
> >> invalidate value returned from front.
> > 
> > It sounds messy and error-prone, to be honest. And any range
> > that needed to
> > implement it and didn't would be broken.
> > 
> > - Jonathan M Davis
> 
> (1) Why/how was it messy/error-prone? Wasn't it doing exactly
> what you want right now?
> 
> (2) How would creating an identical method with a different name
> make the situation better?

He was suggesting that a range like ByLine define consumeFront and then play 
games to make it work. So, instead of doing the equivalent of

auto retval = range.front;
range.popFront();
return retval;

only more efficiently, it would be trying to save state to make the front that 
it returned still be valid, when in ranges like ByLine, it's not, because the 
buffer that front returns is reused. Getting that right is not necessarily 
easy, and regardless of easy it is or isn't to do, it means that any ranges 
which would actually need to define consumeFront specially (due to reusing the 
buffer for front or whatever) in order for consumeFront to work properly would 
be broken unless the programmer who wrote it understood the issues and defined 
consumeFront appropriately. The result is that the default behavior is that 
ranges which don't do the normal thing of having front stay valid will break, 
because they won't have defined consumeFront. The default is unsafe. But if the 
default is that there is no consumeFront, then it'll only be there when the 
programmer determines that they need it and defines it. So, the default is 
safe, but the option of efficiency is there if the programmer codes for it.

Also, creating a function which does the equivalent of

auto retval = range.front;
range.popFront();
return retval;

only more efficiently for a particular range type is easier than it would be to 
do what Roman was proposing, so the likelihood of such being correct is 
higher.

- Jonathan M Davis