shared - i need it to be useful

[Timon Gehr]

On 22.10.18 21:29, Manu wrote:
> On Mon, Oct 22, 2018 at 7:10 AM Simen Kjærås via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>>
>> On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote:
>>> module reborked;
>>> import atomic;
>>>
>>> void main()@safe{
>>>      auto a=new Atomic!int;
>>>      import std.concurrency;
>>>      spawn((shared(Atomic!int)* a){ ++*a; }, a);
>>>      ++a.tupleof[0];
>>> }
>>
>> Finally! Proof that MP is impossible. On the other hand, why the
>> hell is that @safe? It breaks all sorts of guarantees about
>> @safety. At a minimum, that should be un- at safe.
>>
>> Filed in bugzilla: https://issues.dlang.org/show_bug.cgi?id=19326
> 
> Yeah, that's shockingly dangerous for all sorts of reasons!
> I mean, is this really an argument to destroy my proposal,

It was a way to satisfy Simen's (imho, arbitrary) constraint that the 
@safe code should be in a different module.

> or are you just destroying @safe in general?
> 

It is likely that there is @trusted code in the wild that is currently 
broken because of the assumption that private data cannot be modified by 
untrusted actors. I think if we can have e.g. @trusted data that cannot 
be manipulated at all from @safe code (including taking addresses), a 
lot more is possible. shared on variables/fields could then imply @trusted.

It is then however still not clear that it makes sense to allow implicit 
conversion from unshared to shared. It may still be error prone, or even 
impossible to realize. For example, it could hypothetically be the case 
that each processor has its own address space and there is additionally 
some shared address space, in which case allocation would differ for 
data that is shared and data that is unshared.

So I would again like to ask: why can't classes that want to be able to 
have their references implicitly converted to shared and then be sent to 
other threads not just make all members 'shared'? Under your proposal, 
they can never know that they have not already been implicitly converted 
to 'shared' anyway, so any unshared code already needs to take into 
account the possibility that there are other, concurrent accesses.