Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
December 29, 2012 std.range lockstep is not input range but opApply entity. Workarounds? | ||||
---|---|---|---|---|
| ||||
I basically want to be able to do stuff like this: auto result = map!( (a, b) => a+b )( lockstep(range1, range2) ); Are there any standard short ways to wrap an input range around struct with opApply (which Lockstep is)? Also what about redesigning Lockstep as a proper range? I could do a pull request but not sure about current intentions. |
December 29, 2012 Re: std.range lockstep is not input range but opApply entity. Workarounds? | ||||
---|---|---|---|---|
| ||||
Posted in reply to mist | On 2012-48-29 14:12, mist <none@none.none> wrote: > I basically want to be able to do stuff like this: > auto result = map!( (a, b) => a+b )( lockstep(range1, range2) ); > > Are there any standard short ways to wrap an input range around struct with opApply (which Lockstep is)? > > Also what about redesigning Lockstep as a proper range? I could do a pull request but not sure about current intentions. Use std.range.zip instead: auto result = map!( (a, b) => a+b )( zip(range1, range2) ); The reason there are two ways is lockstep works better with foreach: foreach (a, b; lockstep(A, B) ) { // Use a and b here. } Contrast with zip: foreach (a; zip(A, B) ) { // Use a[0] and a[1] here. } There have been suggestions to better integrate tuples in the language, so in the future zip may have all the advantages of lockstep (and vice versa), but don't cross your fingers. -- Simen |
December 29, 2012 Re: std.range lockstep is not input range but opApply entity. Workarounds? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | Any objections to documentation update to cross-reference zip and lockstep to each other? Was not even searching for first one when found lockstep, huh.
On Saturday, 29 December 2012 at 14:19:39 UTC, Simen Kjaeraas wrote:
> On 2012-48-29 14:12, mist <none@none.none> wrote:
>
>> I basically want to be able to do stuff like this:
>> auto result = map!( (a, b) => a+b )( lockstep(range1, range2) );
>>
>> Are there any standard short ways to wrap an input range around struct with opApply (which Lockstep is)?
>>
>> Also what about redesigning Lockstep as a proper range? I could do a pull request but not sure about current intentions.
>
> Use std.range.zip instead:
>
> auto result = map!( (a, b) => a+b )( zip(range1, range2) );
>
> The reason there are two ways is lockstep works better with foreach:
>
> foreach (a, b; lockstep(A, B) ) {
> // Use a and b here.
> }
>
> Contrast with zip:
>
> foreach (a; zip(A, B) ) {
> // Use a[0] and a[1] here.
> }
>
> There have been suggestions to better integrate tuples in the language,
> so in the future zip may have all the advantages of lockstep (and vice
> versa), but don't cross your fingers.
|
December 29, 2012 Re: std.range lockstep is not input range but opApply entity. Workarounds? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | On 12/29/2012 06:19 AM, Simen Kjaeraas wrote: > foreach (a; zip(A, B) ) { > // Use a[0] and a[1] here. > } > > There have been suggestions to better integrate tuples in the language, > so in the future zip may have all the advantages of lockstep (and vice > versa), but don't cross your fingers. Tuples have already been integrated at least as much: :) import std.stdio; import std.range; void main() { int[] cats; int[] birds; foreach (cat, bird; zip(cats, birds)) { writeln(cat, bird); } } Ali |
December 29, 2012 Re: std.range lockstep is not input range but opApply entity. Workarounds? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | Not clever enough to expand like this though:
map!( (a, b) => a+b )( zip(Range1, Range2) );
Using a => a[0]+a[1] is not that big deal though.
On Saturday, 29 December 2012 at 17:58:55 UTC, Ali Çehreli wrote:
> On 12/29/2012 06:19 AM, Simen Kjaeraas wrote:
>
> > foreach (a; zip(A, B) ) {
> > // Use a[0] and a[1] here.
> > }
> >
> > There have been suggestions to better integrate tuples in the
> language,
> > so in the future zip may have all the advantages of lockstep
> (and vice
> > versa), but don't cross your fingers.
>
> Tuples have already been integrated at least as much: :)
>
> import std.stdio;
> import std.range;
>
> void main()
> {
> int[] cats;
> int[] birds;
>
> foreach (cat, bird; zip(cats, birds)) {
> writeln(cat, bird);
> }
> }
>
> Ali
|
December 29, 2012 Re: std.range lockstep is not input range but opApply entity. Workarounds? | ||||
---|---|---|---|---|
| ||||
Posted in reply to mist | On 2012-52-29 20:12, mist <none@none.none> wrote: > Not clever enough to expand like this though: > map!( (a, b) => a+b )( zip(Range1, Range2) ); > > Using a => a[0]+a[1] is not that big deal though. That oughta be doable. However, seeing as std.functional only contains unaryFun and binaryFun (dranges has naryFun), this approach cannot currently extend to tuples with more than two fields. -- Simen |
Copyright © 1999-2021 by the D Language Foundation