View mode: basic / threaded / horizontal-split · Log in · Help
August 29, 2012
Vote for std.digest: ACCEPTED!
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
August 30, 2012
Re: Vote for std.digest: ACCEPTED!
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
August 30, 2012
Re: Vote for std.digest: ACCEPTED!
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
September 04, 2012
Re: Vote for std.digest: ACCEPTED!
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
Top | Discussion index | About this forum | D home