[phobos] Would you find a ByRef range useful?

[Jonathan M Davis]

On 2011-06-06 02:33, Lars Tandle Kyllingstad wrote:
> Sorry for not following up on this earlier, I got busy with other things
> and completely forgot about it.
> 
> On Thu, 2011-05-19 at 18:28 -0400, Robert Jacques wrote:
> > On Thu, 19 May 2011 18:09:09 -0400, Lars Tandle Kyllingstad
> > 
> > <lars at kyllingen.net> wrote:
> > > I can't really see any elegant way to implement save() for such a
> > > range, though, and without save() it doesn't qualify as a forward
> > > range, a bidirectional range or a random-access range -- at least not
> > > as defined by isForwardRange & co.  Is there then any point in
> > > implementing the remaining primitives?
> > > 
> > > -Lars
> > 
> > Well, any routine which uses byRef internally, like I do, won't
> > necessarily care about save, but might use indexing/slicing if available.
> > 
> > Besides, what's wrong with something like:
> > 
> > static if(/*...*/)
> > ByRef save()
> > {
> > 
> > 	auto ptr = new Range;
> > 	*ptr = (*_range).save;
> > 	return byRef(ptr);
> > 
> > }
> 
> A memory allocation hidden away in a function which is normally very
> cheap.  I've somehow gotten the impression that algorithms can use
> save() without worrying about its cost.  After all, in most cases it is
> simply implemented as "return this" or similar.  If it turns out that
> save() makes no such guarantee, I don't see a problem with the
> implementation you suggest.

That's one of the main reasons for the debate on whether postblits can/should 
be assumed to be cheap. If they are, then algorithms can assume that save is 
cheap and be coded accordingly. If they're not, then calling save potentially 
becomes something to be avoided whenever possible. But regardless of whether 
save can be assumed to be cheap, it _definitely_ has the potential to allocate  
memory. And if something critical to a range is on the heap, then you should 
definitely expect a heap allocation in save.

Unfortunately, I'm not sure where the debate on postblits and cost is. As I 
recall, it was pretty much decided that postblits could be assumed to be 
cheap, but then issues with COW and reference counting being properly possible 
(due to bugs in the compiler I suspect, but I don't recall all of the details) 
made it so that decision wasn't as firm IIRC. I think that we still have all 
of the move functions in ranges though, and getting rid of them was one of the 
main goals of assuming that postblits was cheap. So, I really don't know what 
the situation with all that is right now.

But yes. In general, I believe that save is assumed to be fairly cheap.

- Jonathan M Davis