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
