Transience of .front in input vs. forward ranges

[Jonathan M Davis]

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).

- Jonathan M Davis