www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Vote for std.digest: ACCEPTED!

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
The voting ends today, time to count the votes.

With the result of 6 YES votes vs 1 NO std.digest package is accepted 
for inclusion into Phobos.


Congratulations, Johannes.


---

Still, there is one thing that bothers me.

Of few issues that were found (and addressed) during voting there is one 
that requires a global change (in std.algorithm). I'm talking about this 
comment by Andrei:


 * This example:

 copy(oneMillionRange, &ctx); //Note: You must pass a pointer to copy!

 suggests we're doing something wrong. I think a better solution would be
 to have copy() take the target range by "auto ref", and institute this
 passing convention as a general rule for output ranges.


About time to remind us of auto ref and how it works then.
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.

-- 
Olshansky Dmitry
Aug 29 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 30 Aug 2012 00:55:40 +0400
schrieb Dmitry Olshansky <dmitry.olsh gmail.com>:


 The voting ends today, time to count the votes.
 
 With the result of 6 YES votes vs 1 NO std.digest package is accepted 
 for inclusion into Phobos.
 
 
 Congratulations, Johannes.
 


thanks everyone!


 ---
 
 Still, there is one thing that bothers me.
 
 Of few issues that were found (and addressed) during voting there is
 one that requires a global change (in std.algorithm). I'm talking
 about this comment by Andrei:
 
  > * This example:
  >
  > copy(oneMillionRange, &ctx); //Note: You must pass a pointer to
  > copy!
  >
  > suggests we're doing something wrong. I think a better solution
  > would be to have copy() take the target range by "auto ref", and
  > institute this passing convention as a general rule for output
  > ranges.
 
 About time to remind us of auto ref and how it works then.
 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?

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
Aug 30 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Aug 30 2012
parent Johannes Pfau <nospam example.com> writes:
Am Fri, 31 Aug 2012 01:37:10 +0400
schrieb Dmitry Olshansky <dmitry.olsh gmail.com>:


 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.
 


First attempt to implement copyInto:
https://github.com/D-Programming-Language/phobos/pull/772
Sep 04 2012