I wish all qualifiers were revisited with an eye for simplification

Simen Kjærås simen.kjaras at gmail.com
Tue Aug 4 08:22:05 UTC 2020

On Tuesday, 4 August 2020 at 07:38:26 UTC, Sebastiaan Koppe wrote:
> 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.

With DIP1024, any type should be implicitly castable to shared. 
This means you should always be able to call shared methods on 
any object. Far as I can see, this is not implemented.

For a type with no thread-safe interface that means anyone with a 
shared reference to it can call absolutely no methods on it, and 
not read or write any of its fields. Kinda useless, but that's 
the point. If you want to manipulate it, you will need to cast 
away shared, which is non- at safe and a red flag.

For a type with a thread-safe interface, there may be methods 
that can't be called, but some subset will be callable. These 
must be written such that they are thread-safe, and any 
non-shared methods must be written such that they do not break 
the thread-safety of shared methods (but non-shared methods may 
be non-thread-safe if called on multiple threads, since that 
should not happen).

In other words, DIP1024 assumes you will have at most one 
non-shared reference to an object, and that no methods on an 
object are written in such a way that they break thread-safety 
under this assumption.


More information about the Digitalmars-d mailing list