I wish all qualifiers were revisited with an eye for simplification
Sebastiaan Koppe
mail at skoppe.eu
Tue Aug 4 13:52:29 UTC 2020
On Tuesday, 4 August 2020 at 12:52:01 UTC, Manu wrote:
> On Tue, Aug 4, 2020 at 5:40 PM Sebastiaan Koppe via
> Digitalmars-d < digitalmars-d at puremagic.com> wrote:
>> 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.
>
> 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.
What exactly does the compiler need to prove? The restrictions
are all in place, you can only call shared methods on a shared
object, and you can only access shared members in a shared method.
Hmm, well I guess if members themselves were also implicitly
promoted to shared that could cause havoc.
> 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.
Great, I'll try it. Thanks.
More information about the Digitalmars-d
mailing list