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