shared - i need it to be useful

[Manu]

On Sat, Oct 20, 2018 at 9:45 AM Stanislav Blinov via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
>
> > class C {
> >   void f();
> >   void g() shared;
> > }
> >
> > void t1(shared C c) {
> >   c.g; // ok
> >   c.f; // error
> > }
> >
> > void t2(shared C c) {
> >   c.g; // ok
> >   c.f; // error
> > }
> >
> > auto c = new C();
> > spawn(&t1, c);
> > spawn(&t2, c);
> > c.f; // ok
> > c.g; // ok
>
> Those are not "ok". They're only "ok" under Manu's proposal so
> long as the author of C promises (via documentation) that that's
> indeed "ok". There can be no statically-enforced guarantees that
> those calls are "ok", or that issuing them in that order is "ok".
> Yet Manu keeps insisting that somehow there is.

I only insist that if you write a shared method, you promise that it
is threadsafe.
If f() undermines g() threadsafety, then **g() is NOT threadsafe**,
and you just write an invalid program.

You can write an invalid program in any imaginable number of ways;
that's just not an interesting discussion. An interesting discussion
is what we might to to help prevent writing such an invalid program...
I don't suggest here what we can do to statically encorce this, but I
suspect there does exist *some* options which may help, which can be
further developments.

What I also assert is that *this unsafe code is rare*... it exists
only at the bottom of the tooling stack, and anyone else using a
shared object will not do unsafe, and therefore will not be able to
create the problem. If you do unsafety anywhere near `shared`, you
should feel nervous. I'm trying to make a world where you aren't
*required* to do unsafety at every single interaction.

Understand: f() can only undermine g() promise of threadsafety **if
f() is not @safe**. Users won't create this situation accidentally,
they can only do it deliberately.