On Sat, Oct 20, 2018 at 9:45 AM Stanislav Blinov via Digitalmars-d <digitalmars-d@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.