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-@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.

--
   Simen