Shared

[Manu]

On Wed, May 15, 2019 at 2:34 AM Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> [... everything that jonathan said ...]
> ...there's no way that something as free-form
> as locking a mutex on a set of variables that aren't encapsulated in
> anything is going to be able to guarantee that other references to the same
> data don't exist.

This is hard-facts.
We talked about this topic a lot at dconf. Here's where we got to.

Truth #1: shared must not have read/write access. I don't believe
there's any future design where this isn't true. We should do this
now.
Truth #2: Casting shared is not @safe, ever. The language can never
have enough context to know.
Truth #3: If you want something that's useful and @safe, you need to
start building some serious constructions above. Any such construction
necessarily requires tight encapsulation to keep references contained
and only issue leases appropriately.
Truth #4: DIP1000 has a very important part of this; any time you case
shared away (take a lease), the resulting pointer must be `scope`,
otherwise it could be sequestered away, and all bets are off!
Truth #5: I don't think there's anything that can reasonably be
offered at the _language_ level to use shared @safely (other than #1).
Constructions are too varied, and too complex. But I think we know how
to start to write some useful libraries that can safely share data
assuming #1.

I spent some time with Amaury talking through designs for `shared`
shared pointers. We concluded that with DIP1000, there is enough
language available to write a @safe shared object as a library (and no
mutex-es!).
It is clear that any such design requires lease-tracking. It's not
hard to imagine a shared shared-pointer with the same rules as Rust;
"write access may only have 1 lease", "read access many have N
leases", "read/write access are mutually exclusive". The container
would have functions to capture a lease into some raii object, and the
returned object must be DIP1000 `scope`.