DIP 1024--Shared Atomics--Community Review Round 1

[Nicholas Wilson]

On Tuesday, 1 October 2019 at 10:40:52 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community 
> Review for DIP 1024, "Shared Atomics":

Section "Alternatives" should be properly referenced as it makes 
unsubstantiated claims.(Also the references are not linked to 
from the main document).

The linked implementation (which is already merged(!)) appears to 
bear no correlation to the DIP, which appears to suffer a severe 
identity crisis, and as such completely fails the vengeful-ex 
principle:

> This change will require using core.atomic or equivalent 
> functions to read and write to shared memory objects. It will 
> prevent unintended, inadvertent non-use of atomic access.
> ...
> By prohibiting direct access to shared data, the user will be 
> required to use core.atomic and to consider the correctness of 
> their code.

> [The DIP is] just replacing calls to core.atomic with language 
> support...
> This is not pioneering new ground. The only innovation is 
> support by the language type system rather than library calls.
> x=1; // atomic store, release, happens after everything above

So which one is it?
If it is the first, all the references to apparent automatic 
rewriting should be dropped.
If it is the second, I fail to see why this is semantically any 
different to what C++ does with atomic<int>, which the DIP makes 
the claim is controversial.