On Wed, Nov 07, 2012 at 10:40:32PM +0100, Jonathan M Davis wrote: > On Wednesday, November 07, 2012 21:31:13 deadalnix wrote: > > OK, overall, .peekFront seems like a good idea. Something I'm afraid > > with .peekFront is code duplication. > > > > Let's take the joiner example. Joiner's transientness depend on its > > source transientness. This seems to me like a very common case for > > transformer ranges. If we choose the .peekFront, the naive thing to > > do is to implement the same algorithm twice, using front and > > peekFront, which is code duplication, and usually a bad idea. > > Why would you need to duplicate anything?. If you can implement it > using peekFront, then you use peekFront. If you can't, you use front. > And anything which uses front when you could have used peekFront will > still work. Also, if a free function peekFront which forwards to front > is defined, then all range- based functions can use peekFront if they > need it regardless of whether a range defines it (it's just that it > would do the same as front in the case where the range didn't define > it). [...]
Yeah, UFCS will kick in if the range itself doesn't define peekFront, then the free function peekFront will simply call the range's .front instead. So basically: if an algo needs .front to be persistent, they use .front. If they don't care if .front is persistent, they use .peekFront. T -- You are only young once, but you can stay immature indefinitely. -- azephrahel
