[phobos] Would you find a ByRef range useful?

[Lars Tandle Kyllingstad]

On Mon, 2011-06-06 at 02:52 -0700, Jonathan M Davis wrote:
> 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.

Ok, thanks.  That cleared things up -- at least to the extent
possible. :)

-Lars