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.
