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

[rikki cattermole]

On 09/11/2021 10:42 AM, Andrei Alexandrescu wrote:
> 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).

The concern with pure for me is a bit further down the road, 
deallocation (extending/shrinking too). An allocator has state dependent 
on an external global library (i.e. kernel), there is no way around this.

pure should be @nogc effectively. We are faking it right now and that is 
not ok if you care about pure.

> 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.

This is not true.

All pointers have an unknown origin and transitivity of thread ownership 
unless proven otherwise by the compiler during compilation.

Lastly, as far as I'm concerned a reference counted struct should never 
be const (I've gone to great lengths to make it VERY undesirable to end 
up with a const reference counted struct in my stuff). Deadalnix covered 
this with his point 5.