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.
