Ruby-style "each" in D?

Andrei Alexandrescu:

> Pros and cons are already being discussed. Destroy!
>
> https://github.com/D-Programming-Language/phobos/pull/2024

I proposed the same function in D.learn, but this discussion needs a list of use cases and usage examples, otherwise you can't decide in vacuum.

It's named "foreach" in Scala:
http://twitter.github.io/scala_school/collections.html#foreach

Elsewhere I suggested a function that could be named tap() that's usable to debug UFCS chains, interspersing it in the chain, to add imperative calls to writeln. You can replace a each() with a tap + some kind of eager consumer.

In many cases what I want to put in each() is a writef/writefln, you can do it like this (binaryReverseArgs is in std.functional):

foo
.bar
.spam
.binaryReverseArgs!writefln("%(%s-%): %d", 5);

With a shorter flipping name it gets better:

foo
.bar
.spam
.flipTwoArgs!writefln("%(%s-%): %d", 5);

or even (http://zvon.org/other/haskell/Outputprelude/flip_f.html ) (flips only the first two args and doesn't flip the successive ones):

foo
.bar
.spam
.flip!writefln("%(%s-%): %d", 5);

Let's say in each() you want to do something different, like incrementing a variable:

foo
.bar
.spam
.each!(n => x += n);

Is this good enough?

If you want to double the contents of an array:

myArray.each((ref x) => x * 2);

But in D you can also use:

myArray[] *= 2;

I guess you can't use each() on opApply-based iterables, while you can with foreach(). This makes each() less useful.

Is the following code supported? And what is each() receiving from the associative array?

int[string] aa;
aa.each(...);

Perhaps you must use:

int[string] aa;
aa.byKey.each(...);
aa.byValue.each(...);
aa.byPair.each(...);

While arrays should be OK, but there is no index support:

int[] arr;
arr.each(...);

If you need dynamic array index support:

int[] arr;
arr.enumerate.each(...);

Is this supported?

int[10] arr2;
arr2.each(...);

Or do you have to use this?

int[10] arr2;
arr2[].each(...);

Bye,
bearophile

On Wednesday, 19 March 2014 at 16:01:06 UTC, Andrei Alexandrescu wrote: > On 3/19/14, 8:55 AM, Dicebot wrote: >> I would have supported if it was lazy. Not in its proposed form. > > Good point. Maybe forall would be a better name. > > Andrei I think "each" is a good name but it should instead return range that calls predicate function upon "popFront" and proxies input argument further from "front". bearophile has been proposing it under name "tap", but I like "each" more.

On 3/19/14, 9:03 AM, Dicebot wrote: > On Wednesday, 19 March 2014 at 16:01:06 UTC, Andrei Alexandrescu wrote: >> On 3/19/14, 8:55 AM, Dicebot wrote: >>> I would have supported if it was lazy. Not in its proposed form. >> >> Good point. Maybe forall would be a better name. >> >> Andrei > > I think "each" is a good name but it should instead return range that > calls predicate function upon "popFront" and proxies input argument > further from "front". bearophile has been proposing it under name "tap", > but I like "each" more. tee is already being discussed -- Andrei

On Wednesday, 19 March 2014 at 16:04:16 UTC, Andrei Alexandrescu wrote: > tee is already being discussed -- Andrei On this topic, do we have something like "consume" in Phobos to eagerly iterate through the supplied range? Don't see anything similar at first glance and it will be needed to express same idiom via "tap"/"tee" in a readable form.

On 03/19/2014 05:01 PM, Andrei Alexandrescu wrote: > On 3/19/14, 8:55 AM, Dicebot wrote: >> I would have supported if it was lazy. Not in its proposed form. > > Good point. Maybe forall would be a better name. > > Andrei http://en.wikipedia.org/wiki/Forall

On Wednesday, 19 March 2014 at 15:55:14 UTC, Dicebot wrote: > I would have supported if it was lazy. Not in its proposed form. How would it work in lazy form? Or do you mean the "tee" we are talking about in the discussion? The fact that it *isn't* lazy is part of the design (AFAIK). I can't see it work without it.

Forums