shared - i need it to be useful

[Nicholas Wilson]

On Saturday, 20 October 2018 at 16:41:41 UTC, Stanislav Blinov 
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); // line 20
>> spawn(&t2, c); // line 21
>> c.f; // ok
>> c.g; // ok // line 23
>
> 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.

Backing up a bit and making a few observations (after adding 
imports and wrapping the bottom code in a function):

1. the code above currently does not compile, error messages are:
     i.  line 20 & 21: spawn fails to instantiate because c is not 
shared
     ii. line 23: shared method C.g is not callable using a 
non-shared object
     iii. the lines already marked // error

2. in order to fix 1.i, one must cast c to shared at the call 
site, this is not @safe

3 fixing 1.ii requires doing `(cast(shared)c).g`, this is also 
not @safe

4 fixing 1.iii fixing requires casting away shared, this is not 
only not @safe, but also wrong. c is a class so one could try 
locking it although I'm not sure what the implications are for 
doing that when another thread owns the data, probably bad.

5 the current means of dealing with shared with lock and cast 
away shared is also not @safe

6 under Manu's proposal reading and writing shared objects 
results in compilation error

7 The static guarantees we have in the language are type safety 
and @safe

8 under Manu's proposal to do anything one must call shared 
functions on said object, this implies a "@trusted" 
implementation at the bottom of the stack for ensuring thread 
safety (atomics and lock + cast (assuming it is not wrong), other 
sync primitives) that are not @safe, but not outright wrong 
either.

The question then becomes: assuming the implementation _is_ @safe 
type correct and thread safe etc., can the author of C provide 
guarantees of @safe and type correctness? and can this guarantee 
be free of false positives?

Currently the answer is no: the requirement to cast to and from 
shared is un- at safe and that burden is on the user which means 
that they must understand the inner workings of C to know it that 
is the case.

Manu's proposal is slightly more interesting. shared becomes a 
guarantee that accesses to that object will not race, assuming 
that the @trusted implementation at the bottom of the stack are 
correct. In the above if t1 and t2 took `const shared C` and `g` 
was also const shared, then I think that it could.