On "A New Collections Framework for the Standard Library"

[Jonathan M Davis via Digitalmars-d]

On Thursday, May 18, 2017 15:18:00 Jack Stouffer via Digitalmars-d wrote:
> I just got around to watching Eduard Staniloiu's talk at DConf
> [1] about the collections library he was working on. One thing
> seemed odd, in that Eduard seems to be saying that the container
> and the range over the container's elements are one in the same
> and the range primitives are on the container itself.
>
> Is this accurate?
>
> If so, then this is completely different than the currently
> accepted design of ranges and containers. Currently, a container
> allows the removal and insertion of elements, and to get a range
> of the elements you have to call a function or slice the
> container. This is how std.containers and Brain's EMSI container
> library. In this new library, what happens when I iterate the
> elements of one of these containers using foreach? Do the range
> primitives empty the container? How do I ask for a new, full
> range of my data in the collection to use in a range algorithm
> after I've already iterated over the elements?
>
> As Andrei originally laid out in this talk introducing ranges
> [2], ranges only shrink and never grow. Put another way, Output
> Ranges and Input Ranges are two separate things. Andrei states
> durning that talk (at 1:20:20)
>
> "Can ranges ever grow? ... No, never, because it would be
> fundamentally unsafe."
>
> I'm not sure what Andrei meant by this, but he believes that
> growing ranges is also a bad idea.
>
> [1] https://www.youtube.com/watch?v=k88QSIC-Na0
> [2]
> https://archive.org/details/AndreiAlexandrescuKeynoteBoostcon2009

That point concerned me as well. Dynamic arrays in D are very strange beasts
indeed, and while it works for them to function as both ranges and (sort of)
containers, it's also created a fair bit of confusion, and it really a fair
bit of what is done with dynamic arrays are _not_ range-based functions
(e.g. appending), making the whole situation that much more confusing when
range-based functions and array-specific functions are mixed (which is
definitely going to happen in stuff like string code). And a container as a
range really makes no sense to me. It makes slightly more sense than an
iterator being a container (since it is a range of elements not just one),
but it still goes against how containers normally work. A big part of what's
different with dynamic arrays is that they don't actually own or manage
their own memory - rather they refer to memory from elsewhere, and how that
memory is managed depends on where that memory comes from. Yes, after
appending, it can be guaranteed to be the GC, but even then, it's the GC
that manages what goes on with the elements. No one dynamic array owns them,
since you can have multiple of them referring to the same memory. So,
they're quite schizophrenic.

Now, I could see it working to treat a container as a range if you're
talking about _immutable_ containers - especially if their memory is owned
by the GC (and immutable containers are definitely part of what's being
worked on) - since you don't really add to those (at most, you create a new
container with the same elements plus more), but for mutable containers,
that just doesn't seem right.

So, yes, that bit about modeling containers after dynamic arrays greatly
concerns me, but I figured that I'd wait and see the actual API before
complaining about it. And it may very well turn out that what they're doing
actually makes a lot of sense once you actually see the details. I don't
know.

- Jonathan M Davis