On "A New Collections Framework for the Standard Library"

[Eugene Wissner via Digitalmars-d]

On Thursday, 18 May 2017 at 15:18:00 UTC, Jack Stouffer 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

I didn't look the talk yet, but about a month ago I tried to 
implement a similar concept and wanted to apply it to all 
containers as well.
My idea was to make the containers/slices reference counted and 
copy on write (or to be more precise, on size changing, similar 
how D built-in slices behave).

1) All containers have a pointer to the allocated memory and its 
length.
2) All containers have a pointer to the beginning and the end of 
the range they refer to (so popFront, popBack can be implemented 
without changing the real size of the allocated memory)
3) If you do something like insertBack or insertFront and the 
reference counter is greater than 1, then the counter decreases 
and the container is copied.

But at the end I couldn't deal with the constness. Slice!(ubyte) 
and Slice!(const ubyte) are different types - that isn't nice. 
But for "const Slice!ubyte" you can't do popFront and popBack. It 
could be solved with some casting or other hacks but I don't know 
how it would work in a multithreaded envrionment. So I stopped 
the experiment for now.