I wish all qualifiers were revisited with an eye for simplification

[Sebastiaan Koppe]

On Monday, 3 August 2020 at 21:56:34 UTC, Manu wrote:
> Shared recently received a `-preview` which makes it really 
> mean something;
> this is what shared means:
> 1. The data is shared; therefore, it is invalid to read or 
> write that
> memory.
> 2. The reason this is useful as an attribute, is because you 
> are able to
> attribute methods. Ability to author a set of threadsafe 
> methods and
> clearly distinguish them from non-threadsafe methods is a 
> powerful
> advantage over C++.

For some reason I often end up with multiple threads and the 
coordination that comes with it. Shared has been very helpful for 
me and I am using no. 2 with good success.

There is just one thing about shared I don't understand. If I 
design my object such that the non-shared methods are to be used 
thread-local and the shared methods from any thread, it follows 
that I should be able to call said shared methods from both a 
shared and non-shared instance of that object.

Often I workaround it be introducing a non shared method that 
forwards to the shared method by means of casting.

> #2 isn't well accepted, although I've been pushing that for 
> years.

Thanks!

> I think shared has potential to offer critical benefit to D, 
> and we've
> talked about this personally to some length. Don't kill it yet, 
> let's try
> and fix it. Although it's worth recognising that if we don't 
> fix it, then
> it might as well be killed as it stands today.

There might be room for improvement, but it is useful for me 
already. For instance, I often deal with delegates that can be 
called from any execution context. I make them shared to convey 
those semantics and the compiler even helps! Very nice.