On "A New Collections Framework for the Standard Library"

[Jack Stouffer via Digitalmars-d]

On Thursday, 18 May 2017 at 15:18:00 UTC, Jack Stouffer wrote:
> ...

Also, shared allocators raise another problem entirely. Let's say 
for the sake of clarity that these future containers will use a 
separate range type.

Let's say you have a container with five elements, and then you 
give a range of those elements to a function that caches the 
length somewhere because it's available (very common as ranges 
have never been expected to change before). What happens when 
you're iterating over the range and then another thread calls 
removeBack before the loop is completed? All sorts of functions 
in Phobos will blow up in interesting and different ways.

I think you'd have to make all ranges created from mutable 
containers input ranges with no extra primitives in order to 
avoid this problem.

Plus, you also have a problem with things like SList where 
removeFront can be called after a different thread creates a 
range. All of a sudden your range `front` is pointing to invalid 
data. So for that, you need to either

1. Make a thread safe way to invalidate all old ranges (possibly 
by marking them empty immediately)
2. Allow the program to blow-up and mark all remove functions as 
@system