Helping with __mutable (which will be renamed to __metadata)

[Radu]

On Saturday, 13 April 2019 at 03:45:35 UTC, Suleyman wrote:
> On Saturday, 13 April 2019 at 00:45:07 UTC, Andrei Alexandrescu 
> wrote:
>> ...
>
> The problems you encountered are normal but the question is 
> whether this feature is useful at all if the field is not 
> explicitly shared? If so the a solution to the const case is to 
> introduce an '@unshared' attribute instead which would protect 
> against the worst cases of both being shared and being thread 
> local. this attribute would disallow unsychronized read/write 
> and at the same time prevent implicit conversion to 'shared' 
> since it may just be thread local hence mixing it with normal 
> 'shared' may not bring good results.
>
> example:
> ```
> struct S
> {
>     private shared int* p; // or @unshared
>
>     void inc() inout pure @system
>     {
>         import core.atomic;
>         atomicOp!"+="(*cast(shared(int*))p, 1); // or @unshared
>     }
> }
>
> void foo(ref immutable S a) pure
> {
>     a.inc();
> }
>
> void foo(ref const S a) pure
> {
>     a.inc();
> }
>
> int x; // thread local
> shared int y;
>
> void main()
> {
>     auto i = immutable S(cast(immutable)&x);
>     auto c = const S(&y);
>     //auto d = const S(cast(@unshared)&x);
>     foo(i);
>     foo(c);
> }
> ```

I also have the impression that `shared` should be used here 
instead of `__mutable`. Even in the current incarnation shared 
offers some limited guarantees that atomicity is required for 
writing shared values. I think people are working on making 
stronger guarantees for shared.

ATM uses like the one below are a no-op, I think the reuse of 
shared makes sense as it works nicely with the strong thread 
safety guarantees `immutable` has, and also offers the safety net 
for atomic changes. Not to mention that it is not ugly!

immutable struct Foo
{
     shared(int) x;
}