If you could make any changes to D, what would they look like?

[Paul Backus]

On Monday, 25 October 2021 at 20:12:04 UTC, Ola Fosheim Grøstad 
wrote:
> On Monday, 25 October 2021 at 19:52:10 UTC, Paul Backus wrote:
>> It can be assumed not to cause a data race, which means that 
>> an atomic operation on a `shared` variable is exactly as safe 
>> as the corresponding non-atomic operation on a thread-local 
>> variable.
>
> Of course it can't. Let take the simplest of the simple; a 
> struct with a date with 3 fields_ day, month and year. Now, let 
> us assume "2021-10-31". And then we add one day using atomics? 
> How?

I agree that trying to do this with atomics will not give you the 
right answer, but it is at least guaranteed not to cause 
undefined behavior (excluding contract/assertion failures). 
Safety does not imply correctness.

>>> *Thread-local memory locations* are accessible from only one 
>>> thread at a time.
>
> That is way too weak to get the benefits that are desirable, 
> meaning: a competitive edge over C++.
>
> I can create a template-wrapper in C++ too. So, as is, "shared" 
> provides no advantage as far as I can tell.

The advantages are:

1. In C++, such a template wrapper would be opt-in. In D, 
`shared` is opt-out.
2. `@safe` D code can assume that anything non-`shared` is 
thread-local, because only `@system` or `@trusted` code can cast 
to and from `shared`.

In other words, it makes code easier to reason about and 
concurrency bugs easier to isolate.

You are probably correct that `shared` is not very useful for 
enabling compiler optimizations relative to what is possible in 
C++.