I'm back

[H. S. Teoh]

On Mon, Nov 12, 2012 at 03:57:42PM -0800, Andrei Alexandrescu wrote:
> On 11/12/12 3:14 PM, Jonathan M Davis wrote:
> >On Monday, November 12, 2012 12:28:14 Andrei Alexandrescu wrote:
> >>>Topic on range transience probably, as it is
> >>>almost concluded.
> >>
> >>I'm leaning toward doing nothing about this.
> >
> >As it stands, most everything assumes that front is not transient.
> >But then we have ByLine and ByChunk. So, they just plain don't work
> >as ranges for the most part, but they're in the standard library.
> >Either they need to stop being transient or to stop being ranges (and
> >use opApply), or we need to decide on a way to support them being
> >transient as ranges.
> >
> >The best options at this point seem to be to either insist that all
> >ranges have non-transient fronts (and adjust ByLine and ByChunk
> >accordingly) or to go with the peekFront idea. The peekFront idea
> >probably needs some examination though in order to work on the kinks
> >(e.g. letting peekFront and front return different types might be
> >useful in some circumstances, but in general, it's likely to cause a
> >lot of problems if they don't both return ElementType!R).
> 
> Here are two thoughts:
> 
> 1. The notion of "this is an input range that is not a forward
> range, AND the element type has mutable indirections so it's not a
> proper value type" is a very close approximation of transiency. We
> could define that as a trait and have interested algorithms consult
> it.
> 
> 2. I'm reversing my attitude toward peekFront for the simple reason
> I've been there: moveFront, moveBack, and moveAt. And it's not a
> pretty place to be in. As soon as we're discussing peekFront there's
> the question of supporting peekBack and peekAt. I'm pretty sure
> people, if sufficiently motivated, will find examples of
> bidirectional and random-access transitory ranges that motivate such
> primitives.
[...]

You're right, introducing peekFront will lead to peekBack and peekAt,
and it will add a lot of complications. I think the original .transient
proposal is sounding more attractive at this point.

But anyway, it seems that this issue is going nowhere. At this point,
I'm ready to just declare all transient ranges illegal and leave it at
that.  I'll just duplicate std.algorithm where I need to work with
transient ranges, as it's proving impossible to make any progress on
this front. Short of defining a universal way of saying "I want to
*duplicate* this value, not just get another reference to it", I don't
see any way of solving this problem without introducing all sorts of
complications. Unfortunately, using ranges in their most general sense
is looking like a pipe dream to me right now, and I'm ready to just move
on.

(I still wish Phobos algorithms would be written to not rely on the
persistence of .front where possible, as I regard it as sloppy
programming otherwise, but that's just IMAO, and in any case, it doesn't
seem like anything is going to get done about it anyway, so let's just
strike out transient ranges once for all and leave it at that.)


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.