Challenge: write a reference counted slice that works as much as possible like a built-in slice

[Andrei Alexandrescu]

This was prompted by this exchange with Paul Backus that went like this:

Me: "We never got reference counting to work in safe pure nogc code. And 
we don't know how. If we did, we could write a slice-like type that does 
everything a slice does PLUS manages its own memory. This is the real 
problem with containers."

Paul: "I'm pretty sure at least some of us (including Atila) know how."

===

Eduard Staniloiu (at the time a student I was mentoring) tried really 
hard to define a built-in slice RCSlice(T) from the following spec:

- be as close in semantics to T[] as possible, i.e. most code should be 
able to simply replace T[] with RCSlice!T and work unchanged
- manage its own memory by using reference counting
- work in pure code just like T[] does
- work with qualifiers like T[] does, both RCSlice!(qual T) and 
qual(RCSlice!T)
- work in @nogc code just like T[] does
- work in @safe code just like T[] does

We were unable to define that within the limits of D. Here are the major 
issues we encountered:

1. We could not make reference counting work properly in pure functions 
(a pure function does not mutate data, which goes against manipulating 
the reference count).

2. Qualifiers compound problems with interlocking: mutable data is known 
to be single-threaded, so no need for interlocking. Immutable data may 
be multi-threaded, meaning reference counting needs atomic operations. 
Const data has unknown origin, which means the information of how data 
originated (mutable or not) must be saved at runtime.

3. Safety forced the use of trusted blocks all over. Not a showstopper, 
but a complicating factor.

So if there are any takers on getting RCSlice off the ground, it would 
be very interesting.