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.
Yes, this is a thing I talked at great length 1-2 years ago.
If you take shared to mean "is thread-safe", then my idea was that not-shared -> shared implicit conversion should be possible.
What I often do is this:
struct Thing
{
ref shared(Thing) implSharedCast() { return *cast(shared)&this; }
alias implSharedCast this;
}
If that were an implicit conversion, that implies a slight change of meaning of shared (to one that I consider immensely more useful), but it's more challenging for the compiler to prove with confidence, and there's a lot of resistance to this change.
In the mean-time, until the shared usage patterns are more well-proven, I recommend you try to use the 'alias this' pattern I show above, and report on any issues you encounter using this scheme. If no issues are identified with extensive real-world usage data, I will push again for that implicit conversion rule.