Transience of .front in input vs. forward ranges

[deadalnix]

Le 06/11/2012 08:17, Jonathan M Davis a écrit :
> If we defined peekFront via UFCS as a wrapper which calls front, then anything
> wanting to use peekFront could use peekFront regardless of whether the type
> defined it or not. So, that would reduce the impact caused by its introduction,
> but it would still impact a lot of range types ultimately, because we'd have
> to create appropriate wrappers for peekFront in most of them, or we'd end up
> making unnecessary copies.
>

Assuming you call front on the source range, you don't need to copy : 
you already work on a clean copy.

With that one, you ends up duplicating all code that use front on 
wrapper range into one that use peekFront as well. I'm not sure this is 
better than .transient, but maybe.

> I don't like how much this impacts, but as H. S. Teoh points out, we don't
> exactly have very many options with minimal impact beyond banning transient
> fronts entirely (which I'd honestly like to do just the same).
>

If we really want to go simple, this seems like the way to go.

> At least this avoids the need to create more traits to test ranges for, since
> if we create a free function peekFront, all range types can just assume that
> it's there and create wrappers for it without caring whether the wrapped range
> defines it itself or uses the free function. And it's less complicated than the
> .transient suggestion. Though it _does_ introduce the possibility of front and
> peekFront returning completely different types, which could complicate things a
> bit. It might be better to require that they be identical to avoid that
> problem.
>

I'm not sure yet this is simpler.

> For better or worse though, this approach would mean that byLine (or eachLine
> or whatever) wouldn't be reusing the buffer with foreach like they do now,
> though I suppose that you could make them have opApply which does the same
> thing as now (meaning that it effectively uses peekFront), and then any range-
> based functions would use front until they were updated to use peekFront if
> appropriate. But then again, maybe we want byLine/eachLine to copy by default,
> since that's safer, much as it's less efficient, since then we have safe by
> default but still have an explicit means to be more efficient. That fits in well
> with our general approach.
>

Safe by default seems like the way to go.

> peekFront may be the way to go, but I think that we need to think through the
> consequences (like the potential problems caused by front and peekFront
> returning different types) before we decide on this.
>

Yes especially string/char[] has already been detected as a potential 
problem.