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

[Ola Fosheim Grøstad]

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?

If I declare something as shared as a type, then I expect some 
solid means to protect it.

The current setup is too naive to be useful. It is no better than 
a wrapper-template. It does not need to implemented in the type 
system. It could have been implemented as a regular library.

This is not to say that the concept of "shared" is not useful. It 
is the might-as-well-have-been-a-template-wrapper-approach that 
is useless.

> [The language spec][1] defines "thread local" as follows:
>
>> *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.

> And further clarifies that
>
>> A memory location can be temporarily transferred from shared 
>> to local if synchronization is used to prevent any other 
>> threads from accessing the memory location during the 
>> operation.
>
> Of course, the compiler will not stop you from writing 
> incorrect casts in `@system` code, but that's not an issue 
> unique to `shared`.


I don't see how this can be guaranteed. The compiler _needs_ to 
know where the line in the sand is drawn so that is isn't limited 
by the potentially performance-limiting sequencing points that 
C++ has to deal with.

For instance: what are the lifetimes for cached computations when 
you don't know if another thread will obtain access to what you 
received as a "nonshared object"?

Also, in order to get solid GC performance the compiler needs to 
know whether the memory is owned by the thread or is foreign to 
it.

"shared" has to be more than a shell in order to enable more 
"power"...