Transience of .front in input vs. forward ranges

[H. S. Teoh]

On Sun, Nov 04, 2012 at 08:42:42PM -0800, Jonathan M Davis wrote:
> On Sunday, November 04, 2012 20:20:58 H. S. Teoh wrote:
> > What's not to like about this proposal?
> 
> It creates massive code duplication all over the place, and it's yet
> one more range concept that everyone has to remember and keep in mind.

It doesn't require code duplication at all. Users don't have to know
what .transient is. They just write a non-transient range and everything
works.


> Remember that ranges are supposed to be perfectly writable by the
> average D user, not just Phobos devs. And this complicates them yet
> further. If anything, we need to _simplify_ ranges, not make them more
> complex (e.g. getting rid of the move* functions). And this proposal
> not only makes them more complex, it ends up requiring that a lot more
> code be written.

It only requires more code where more code is needed (see my other post
for an example of how the new version of ByLine can implement .transient
with hardly any code duplication).


> Sure, the fact that ranges are non-transient by default reduces the
> problem, but that just means that it's that much less likely to
> actually be used, meaning that we're complicating ranges even further
> for something that most people are going to forget about completely.

Which is kinda the point -- most people who don't care about the
difference between transient and non-transient ranges don't have to do a
thing, and everything Just Works.

People who *do* care simply write code that's aware of .transient, and
they get to enjoy better performance. If some Phobos code is made
transient-aware, users get to reap the benefit without needing to know
what .transient is.


> I honestly think that you're pushing for an incredibly abnormal use
> case here, and that it's just not worth the extra complication that it
> requires.

It's not abnormal at all to me. It's perfectly natural to want to reuse
buffers for the sake of better performance. Being *required* to call
.dup on everything, or having to rewrite std.algorithm because I can't
use it with transient ranges, is what's abnormal.

The whole idea behind ranges is sequential access -- there's nothing
inherent about sequential access that says returned elements must be
persistent. That's just limiting the scope of the concept's
applicability by arbitrary assumption rather than any actual conceptual
need.


> It's bad enough to be stuck trying to support transient fronts with
> input ranges, but input ranges are so useless in general that it may
> actually end up affecting very few functions in reality.

Exactly, so only those few functions actually need to be changed.
Everything else stays the same.


> Anything like isTransient or transient or fastRange affects
> _everything_,

It doesn't. If the code isn't changed, it just defaults to non-transient
ranges, which is what you were pushing for in the first place. And just
to be clear, input ranges will *also* be non-transient by default. So no
massive code change is needed.


> and just because it can be added in piece by piece instead of all at
> once doesn't change that fact. It just allows us to spread out the
> work.
[...]

It lets us add code only where transience matters, which is with things
like byLine, and a few algorithms that actually care to take advantage
of transient ranges. Nothing else is affected. It certainly doesn't
affect "everything" -- if indeed, as you say, transient ranges are rare
occurrences.


T

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