shared - i need it to be useful

[Stanislav Blinov]

On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves wrote:
> On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
>> 1. shared should behave exactly like const, except in addition 
>> to inhibiting write access, it also inhibits read access.
>
> How is this significantly different from now?
>
> -----------------
> shared int i;
> ++i;
>
> Error: read-modify-write operations are not allowed for shared 
> variables. Use core.atomic.atomicOp!"+="(i, 1) instead.
> -----------------
>
> There's not much one can do to modify a shared value as it is.

i = 1;
int x = i;
shared int y = i;

And so on. The compiler needs to forbid this.

> Unless I'm missing something, I can't arbitrarily do anything 
> with shared members right now.

Except arbitrarily read and write them :)

>> From there, it opens up another critical opportunity; T* -> 
>> shared(T)*
>> promotion.

> I don't think that works. See below.

Welcome to the club.

>> Assuming the rules above: "can't read or write to members", 
>> and the understanding that `shared` methods are expected to 
>> have threadsafe implementations (because that's the whole 
>> point), what are the risks from allowing T* -> shared(T)* 
>> conversion?
>
> int i;
> tid.send(&i);
> ++i;  // oops, data race

Doesn't work. No matter what you show Manu or Simen here they 
think it's just a bad contrived example. You can't sway them by 
the fact that the compiler currently *prevents* this from 
happening.

>> All the risks that I think have been identified previously 
>> assume that you can arbitrarily modify the data.

> Do you have any examples of arbitrarily modifying shared data? 
> I can't think of any.

See near the beginning of this post ;)

>> That's  insanity... assume we fix that... I think the 
>> promotion actually becomes safe now...?
>
> I don't think so, no.

+100500.