I want to do something like this (Collection is a custom type):

Collection x = new Collection();
x.add(something);
x.add(somethingElse);

foreach(type value; x)
{
    writeln(value);
}

Collection is a class with a private array member variable which actually holds the collection data entered via the add method. What do i need to add to the Collection class to make it iterable (whilst it's actually iterating through the member array) so the foreach loop works as expected?

On Wednesday, October 17, 2012 00:03:46 Gary Willoughby wrote:
> I want to do something like this (Collection is a custom type):
> 
> Collection x = new Collection();
> x.add(something);
> x.add(somethingElse);
> 
> foreach(type value; x)
> {
> writeln(value);
> }
> 
> Collection is a class with a private array member variable which actually holds the collection data entered via the add method. What do i need to add to the Collection class to make it iterable (whilst it's actually iterating through the member array) so the foreach loop works as expected?

1. Define opApply (see section labeled "Foreach over Structs and Classes with opApply after here: http://dlang.org/statement.html#foreach_with_ranges)

2. Or make it a range (see http://dlang.org/statement.html#foreach_with_ranges and http://ddili.org/ders/d.en/ranges.html ), which would probably be a bad idea, since containers really shouldn't be ranges.

3. Or do what std.container does and overload opSlice which returns a range over the container (see http://dlang.org/operatoroverloading.html#Slice and http://dlang.org/phobos/std_container.html in addition to the links in #2). Overall, this is the best approach.

But regardless of which approach you take, you really should read up on ranges if you want to be doing much with D's standard library, and http://ddili.org/ders/d.en/ranges.html is the best tutorial on them at this point. There's also this recent article by Walter Bright which explains one of the main rationales behind ranges:

http://www.drdobbs.com/architecture-and-design/component-programming-in- d/240008321

- Jonathan M Davis

On 2012-10-17 00:23, Jonathan M Davis wrote:

> 2. Or make it a range (see http://dlang.org/statement.html#foreach_with_ranges
> and http://ddili.org/ders/d.en/ranges.html ), which would probably be a bad
> idea, since containers really shouldn't be ranges.

Why is that a bad idea?

-- 
/Jacob Carlborg

On Wednesday, October 17, 2012 08:14:45 Jacob Carlborg wrote:
> On 2012-10-17 00:23, Jonathan M Davis wrote:
> > 2. Or make it a range (see http://dlang.org/statement.html#foreach_with_ranges and http://ddili.org/ders/d.en/ranges.html ), which would probably be a bad idea, since containers really shouldn't be ranges.
> 
> Why is that a bad idea?

For starters, iterating over the container would empty it.

- Jonathan M Davis

On 2012-10-17 08:17, Jonathan M Davis wrote:

> For starters, iterating over the container would empty it.

Right, but that is really weird, in my opinion.

-- 
/Jacob Carlborg

On Wednesday, October 17, 2012 08:58:33 Jacob Carlborg wrote:
> On 2012-10-17 08:17, Jonathan M Davis wrote:
> > For starters, iterating over the container would empty it.
> 
> Right, but that is really weird, in my opinion.

Well, what would you expect? Ranges are consumed when you iterate over them. So, if an container is a range, it will be consumed when you iterate over it. That's the way that it _has_ to work given how ranges work, and that's why you overload opSlice to return a range which is iterated over rather than making the container itself a range.

- Jonathan M Davis

On 2012-10-17 17:45, Jonathan M Davis wrote:

> Well, what would you expect? Ranges are consumed when you iterate over them.
> So, if an container is a range, it will be consumed when you iterate over it.
> That's the way that it _has_ to work given how ranges work, and that's why you
> overload opSlice to return a range which is iterated over rather than making
> the container itself a range.

How does this work with built-in arrays?

-- 
/Jacob Carlborg

On Wed, Oct 17, 2012 at 06:58:52PM +0200, Jacob Carlborg wrote:
> On 2012-10-17 17:45, Jonathan M Davis wrote:
> 
> >Well, what would you expect? Ranges are consumed when you iterate over them.  So, if an container is a range, it will be consumed when you iterate over it.  That's the way that it _has_ to work given how ranges work, and that's why you overload opSlice to return a range which is iterated over rather than making the container itself a range.
> 
> How does this work with built-in arrays?
[...]

If I understand it correctly, arrays work because when you pass an array to a range function, you're actually passing a slice of it to the function. That slice gets consumed, but the original array is unchanged.


T

-- 
A linguistics professor was lecturing to his class one day. "In English," he said, "A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative." A voice from the back of the room piped up, "Yeah, yeah."

On 10/17/2012 09:58 AM, Jacob Carlborg wrote:
> On 2012-10-17 17:45, Jonathan M Davis wrote:
>
>> Well, what would you expect? Ranges are consumed when you iterate over
>> them.
>> So, if an container is a range, it will be consumed when you iterate
>> over it.
>> That's the way that it _has_ to work given how ranges work, and that's
>> why you
>> overload opSlice to return a range which is iterated over rather than
>> making
>> the container itself a range.
>
> How does this work with built-in arrays?

Array is a separate concept than slice; a slice provides access to the elements of an array. Arrays are containers that are owned by the runtime, slices are ranges over their elements. Only the slices are consumed.

Ali

On Wednesday, October 17, 2012 10:08:15 H. S. Teoh wrote:
> On Wed, Oct 17, 2012 at 06:58:52PM +0200, Jacob Carlborg wrote:
> > On 2012-10-17 17:45, Jonathan M Davis wrote:
> > >Well, what would you expect? Ranges are consumed when you iterate over them. So, if an container is a range, it will be consumed when you iterate over it. That's the way that it _has_ to work given how ranges work, and that's why you overload opSlice to return a range which is iterated over rather than making the container itself a range.
> > 
> > How does this work with built-in arrays?
> 
> [...]
> 
> If I understand it correctly, arrays work because when you pass an array to a range function, you're actually passing a slice of it to the function. That slice gets consumed, but the original array is unchanged.

Pretty much yeah. Thinking of arrays in D as containers in a mistake really. They're not, as weird as that may be. It's the runtime (or the block of memory in the runtime, depending on how you look at it) which is the container, and the array is just a slice into it.

But even that's not really an accurate way of looking at it, because you can append to them (altering the size of the underlying container and possibly resulting in them pointing to a different block of memory). Kind of like how arrays are halfway between value types and reference types, they're sort of halfway between ranges and containers. It's quite unfortunate that arrays are by far the most commonly used type of range, because they're a horrible example of one when you get down to the details of how they work.

Regardless, it's slicing that you're dealing with when doing range-based operations on arrays, so it's the slice that gets operated on and consumed rather than the original array. And just like how ranges which are structs normally get automatically saved when passed to functions, arrays automatically get saved because they get sliced. And foreach doesn't even use the range API on arrays anyway, so regardless of how they work as ranges, it wouldn't necessarily apply to foreach.

- Jonathan M Davis