On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
While I work on making std.allocator better, here's some food
for thought regarding std.collection.
Consider a traditional container with reference semantics,
Java-style. Regarding changing the collection (e.g.
adding/removing elements) while iterating, we have the
following possibilities:
1. Leave it undefined, like the STL does. Probably this is too
extreme.
2. Throw an exception if a remove is attempted while ranges
exist. This works but it's conservative - e.g. it throws even
if those ranges are never to be used again etc.
3. Allow the removal but throw from the ranges if there's any
attempt to use a range following a remove.
4. Make it work such that ranges continue to be valid post
removal. Perhaps this is on the inefficient side.
Andrei
I think the best approach is the following:
* Throw exceptions on debug (usability)
* Leave undefined on release (performance)
* Implement another set of collections in
std.collections.persistent that allows modification of ranges
without invalidating original range (or changing, aka supports
snapshotting)that could be referenced somewhere else including
another thread. Modifications would return a new reference rather
than be done in place and collections in this namespace are
immutable.