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
