[Issue 9102] OutputRange should be ref parameter

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Feb 25 10:14:35 PST 2013


http://d.puremagic.com/issues/show_bug.cgi?id=9102



--- Comment #6 from Steven Schveighoffer <schveiguy at yahoo.com> 2013-02-25 10:14:31 PST ---
I think citing put as justification is not exactly correct.  put is a basic
operation of an output range.  It is meant to be used basically as a method of
the output range, and is meant to modify it's owner.  Considering that methods
always ref their owners, this is a valid practice.

On the other hand, copy's output range is a target, not its owner.  Copy is an
algorithm.  There are valid use cases for having copy consume the output range,
and valid cases for having it not consume the output range (for those output
ranges that might choose to have partially value-like passing).

However, a type without a reference cannot really be a valid output range,
since an output range should not only operate on value-passed data.  In
essence, such a type is not an output range, but a reference to that type is. 
I don't think it's good practice to burden functions that USE output ranges
with the requirement that they figure out how to the parameter a valid output
range.  Such design is impossible for the function to get right.  Making the
wrong decision can critically affect the side effects, and destroy any
intentions of the output range's author.

The only exception I can think of is a range that intentionally throws away
data.  Like a > /dev/null type of redirect.

Actually, any type can be made into an output range if it has a put-like
function, even if it has no references, by using a pointer to an instance, or
creating an instance on the heap.  Perhaps a auto outputRange(string method,
T)(ref T t) function could be useful:

struct CRC32
{
   void ingest(ubyte[]) {...}
}

CRC32 crc;
copy(ary3, outputRange!"ingest"(crc));

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list