Transience of .front in input vs. forward ranges

[H. S. Teoh]

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