On Wed, 21 Jul 2010 23:56:20 -0400, Walter Bright
<[email protected]> wrote:
Peter Alexander wrote:
== Quote from Walter Bright ([email protected])'s article
If some algorithms used ranges and others used iterators, the
poor programmer
would find himself then obliged to implement both interfaces for
each container.
This makes no sense.
I don't understand why you see ranges and iterators as conflicting
concepts. The cursors/iterators are for referring to individual
elements, and ranges are for specifying iterations over a sequence.
Right, so the container programmer is obliged to implement both.
With std.container, nobody is obliged to implement anything. If you look
at the model, everything is referred to as Stuff, which can be anything.
To further this point, SList accepts *two* types of ranges, a normal SList
range, and a Take!(Slist.Range) range. Really, a cursor is a Take range
of length 1, so it's not a big leap to add such ranges.
Also note that typically, "supporting another range type" can be as easy
as adding another branch to the template constraint if statement.
There aren't two competing interfaces here. If your interface
requires a range of elements, you use a range. If it only needs a
single element, you use a cursor.
The algorithm is the one doing the requiring, not the container. So, if
there are standard algorithms some of which require ranges and others
that require interfaces, the container implementor is obliged to provide
both.
Now you are just misinterpreting :) Nobody said anything about D
interfaces.
And ranges are supersets of cursors. All ranges of containers can provide
a cursor of the front element. All dcollections ranges provide both begin
and end cursors, so if you have a range and you need a cursor, it's just
an accessor.
All I would like to see is some way to generically point to a
single element in a range.
range[0] ?
That only works on arrays, therefore it is not generic.
Any range can provide a [0] interface.
First, that is patently incorrect. You cannot provide a [0] interface,
you can only provide a [int] interface. Which means you must throw on all
values other than 0, and that is absolutely appalling.
Second, when he says point to a single element, he doesn't mean point to
any element picked by the container, he means point to a *specific*
element. For example, he may want a pointer to the second element.
There is the massive unsafeness of using iterators. We'd like
the whole of the
algorithms to be guaranteed memory safe, and that cannot happen
with iterators.
Being able to statically guarantee memory safety is a huge deal,
and the larger
a program is and the larger the team working on it, the more
this matters.
The iterators would not need to be used for iterations.
Perhaps calling them iterators, then, is a source of confusion!
Yeah, dcollections changed iterators to cursor early on to avoid the
confusion with C++ iterators, which they are not.
-Steve
