http://d.puremagic.com/issues/show_bug.cgi?id=9102
--- Comment #6 from Steven Schveighoffer <[email protected]> 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: -------
