Vote for std.digest: ACCEPTED!

[Dmitry Olshansky]

On 30-Aug-12 12:33, Johannes Pfau wrote:
> Am Thu, 30 Aug 2012 00:55:40 +0400
[snip]

>> The end result is we need to get a version of copy that:
>> - doesn't break existing code
>> - takes destination by ref when possible thus fixing this pattern.
>>
>
> Would it be good enough if we special cased arrays to have the same
> behavior as now and used 'auto ref' for all other output ranges?
>
> I think we can't avoid breaking some code though. If some code relied on
> the second parameter being passed by value, there's nothing we can do?
>

Yes, that's the catch. Even introducing special case for arrays doesn't 
prevent code breakage.

> E.g:
> ----
> auto a = copy([0], start); // a = start ~ 0
> auto b = copy([1], start); // b = start ~ 1
> auto c = copy([2], start); // c = start ~ 2
>

Then it seems to me that the only way out is to 'educate the masses' on 
the proper copy idiom. And we already have sort of the same thing with 
std.algorithm.remove.
Interestingly, copy documentation doesn't indicate how output ranges 
work with it, instead focusing on arrays and (probably) forward ranges.
AFAICT output range doesn't have a "leftover" portion.

What about adding copyInto algorithm that requires output range and 
leaves the usual copy to work on forward ones? (it then would require 
ref argument or class instance obviously).

A couple of releases ago I actually added one function in what I was 
meant to be a family of functions. The aim of *Into was to fix 
allocation happiness of e.g. replace and similar algorithms when the 
resulting object is created only to be forwarded to some output range:

http://dlang.org/phobos/std_array.html#replaceInto
(that reminds me to add std.regex.replaceInto)

The other use case is e.g. preallocated buffers, and ATM it seems the 
only way to get GC-free replace/join etc. before we get allocators.

-- 
Olshansky Dmitry