On Wednesday, July 04, 2012 10:43:04 Roman D. Boiko wrote: > On Wednesday, 4 July 2012 at 08:31:05 UTC, Jonathan M Davis wrote: > > 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. > > OK, you sold it to me :) If some developer decides to use > consumeFront for efficiency reasons, it should not be a problem > to statically check hasConsume. What I was trying to avoid was > code bloat at clients, assuming that they used consumeFront to > have less code (one call instead of two). That would be a very > different use case, and currently proposed design doesn't fit > that use case. But it is really minor comparing to potential risk.
If someone really wants to reduce code, they can easily write a wrapper that does auto retval = range.front; range.popFront(); return retval; and then it's up to them to deal with the consequences if they use it on a range where that's not valid. But reducing code was never my concern (nor Dmitry's in considering proposing essentially the same thing). It's efficiency that's the problem - particularly with strings. IIRC, with the tests that I ran, it took about 33% longer to use front and popFront separately than it did to use consumeFront with strings. As great as ranges are, they definitely have some efficiency issues with strings, and if we can introduce some basic changes which make it possible for them to be more efficient, it could be a big win. - Jonathan M Davis
