On Monday, 11 August 2014 at 18:20:51 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
If you make your linked list container the same thing as a
range over it, then iterating over the range will empty the
container as
well, which generally isn't what you want.
Yes but only if it's been implemented purely as an input range. I
was wondering if it was implemented as a forward range. Forward
ranges allow iteration without destroying the contents. I was
wondering how the 'save' method of the forward range could be
implemented with a linked list. If my understanding is correct
this method yields a copy to iterate over and discard.
It's much better to separate the container itself from ranges
over the
container. This then allows you to have separate container
methods that
return ranges of different types.
That does answer it partially. This abstraction could return
ranges over the nodes or items. but ultimately these have to
expose the underlying data or provide a copy. (i.e. the 'save'
method of forward ranges.)
Also iterating in reverse (which should be possible with a doubly
linked list) such ranges will have to be bidirectional ranges.
These questions are all kind of inter-linked. I want to iterate
forward and back through the list and if possible provide a nice
public interface. It doesn't seem right to expose the nodes as
that smells of a leaking abstraction. Hiding the nodes make it
harder to iterate without a nice interface i.e. bidirectional
range.
Ranges are nice but the (forward range's) 'save' method needs
careful consideration. opApply is nice but i can't see a way to
overload it for reverse iteration.
