import std.container;
import std.stdio;


void main()
{
   DList!int list;
   Array!(DList!int.Range) stack;
   foreach(i; 0 .. 4)
   {
      list.stableInsertBack(i);
      stack.insertBack(list[]);
   }

   writefln("list: %s", list[]); // fine
   writefln("stack: %s", stack[]); //fine

   foreach(s; stack[])
      writefln("s: %s", s); // all s are empty?

   writefln("stack: %s", stack[]); //not fine
}

It prints:

list: [0, 1, 2, 3]
stack: [[0], [0, 1], [0, 1, 2], [0, 1, 2, 3]]
s: []
s: []
s: []
s: []
stack: [[], [], [], []]

On Wednesday, 25 February 2015 at 09:07:17 UTC, Tobias Pankrath wrote:
> import std.container;
> import std.stdio;
>
>
> void main()
> {
>    DList!int list;
>    Array!(DList!int.Range) stack;
>    foreach(i; 0 .. 4)
>    {
>       list.stableInsertBack(i);
>       stack.insertBack(list[]);
>    }
>
>    writefln("list: %s", list[]); // fine
>    writefln("stack: %s", stack[]); //fine
>
>    foreach(s; stack[])
>       writefln("s: %s", s); // all s are empty?
>
>    writefln("stack: %s", stack[]); //not fine
> }
>
> It prints:
>
> list: [0, 1, 2, 3]
> stack: [[0], [0, 1], [0, 1, 2], [0, 1, 2, 3]]
> s: []
> s: []
> s: []
> s: []
> stack: [[], [], [], []]

Ranges aren't containers. It's more like a view of a container that gets smaller (or empty) the more you use it. There might not be a container behind a range.

Tobias Pankrath wrote:

>     writefln("stack: %s", stack[]); //fine

This call consumes all ranges stored in stack, so they're empty afterwards.

On 2/25/15 4:58 AM, Ivan Timokhin wrote:
> Tobias Pankrath wrote:
>
>>      writefln("stack: %s", stack[]); //fine
>
> This call consumes all ranges stored in stack, so they're empty afterwards.
>

This has to be a bug. stack[] should produce a range that can be iterated without destroying the data in the container. If it doesn't, it should be supported.

-Steve

On Thursday, 26 February 2015 at 15:57:22 UTC, Steven Schveighoffer wrote:
> On 2/25/15 4:58 AM, Ivan Timokhin wrote:
>> Tobias Pankrath wrote:
>>
>>>     writefln("stack: %s", stack[]); //fine
>>
>> This call consumes all ranges stored in stack, so they're empty afterwards.
>>
>
> This has to be a bug. stack[] should produce a range that can be iterated without destroying the data in the container. If it doesn't, it should be supported.
>
> -Steve

Haven't looked into it, but I'd rather say that writefln (or formattedWrite, or what is used) should only take ranges per ref, if they cannot be copied and cannot be saved.

On 2/26/15 11:07 AM, Tobias Pankrath wrote:
> On Thursday, 26 February 2015 at 15:57:22 UTC, Steven Schveighoffer wrote:
>> On 2/25/15 4:58 AM, Ivan Timokhin wrote:
>>> Tobias Pankrath wrote:
>>>
>>>>     writefln("stack: %s", stack[]); //fine
>>>
>>> This call consumes all ranges stored in stack, so they're empty
>>> afterwards.
>>>
>>
>> This has to be a bug. stack[] should produce a range that can be
>> iterated without destroying the data in the container. If it doesn't,
>> it should be supported.
>>
>> -Steve
>
> Haven't looked into it, but I'd rather say that writefln (or
> formattedWrite, or what is used) should only take ranges per ref, if
> they cannot be copied and cannot be saved.

OK, this is more complex than I thought. Both stack[] and list[] are providing copies.

I mistakenly thought that because stack prints empty that the list has been emptied. It hasn't, just the ranges are emptied.

Yes, I agree, it's writefln that should be fixed here.

-Steve