Proposal: takeFront and takeBack

[Jonathan M Davis]

On Thursday, July 05, 2012 00:03:02 Timon Gehr wrote:
> On 07/04/2012 11:53 PM, deadalnix wrote:
> > Le 04/07/2012 20:40, Jonathan M Davis a écrit :
> >> On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
> >>>> Many languages does this (it doesn't mean it is the right thing
> >>>> to do). Do you know why this shouldn't be done ?
> >>> 
> >>> In C++ it was exception safety, wasn't it?
> >> 
> >> I believe that it was purely a question of speed. If popFront returns an
> >> element, then that element gets copied, and if you didn't need to
> >> access the
> >> element, then that's wasted cycles. You have to worry about exceptions in
> >> either case, depending on the what popFront is doing.
> >> 
> >> - Jonathan M Davis
> > 
> > If you return by reference, you get an overhead of 1 MOV instruction.
> > This is ridiculous.
> 
> You get an 'overhead' of calling front, which is potentially unbounded.
> 
> struct Map(...){
>      ...
>      @property auto ref front() { return f(otherRange.front); }
> }

Not to mention, in many cases, you _can't_ return a ref like deadalnix 
suggests, because that would require that front be returning an lvalue, and it 
often isn't. And in the case of strings - which is the prime reason for this 
discussion in the first place - it definitely can't return an lvalue, because 
front is calculated (that and returning a value from popFront would make 
popFront much more expensive in the case where you _don't_ actually need to 
access front, so making popFront return an element doesn't help the string 
case at all).

- Jonathan M  Davis