I wish all qualifiers were revisited with an eye for simplification

[Timon Gehr]

On 04.08.20 15:52, Sebastiaan Koppe wrote:
> 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.
> ...

Nope. You can access all members, but they will be treated as `shared`.

> Hmm, well I guess if members themselves were also implicitly promoted to 
> shared that could cause havoc.

Which is what the code above does, and also what Manu's "thread safe" 
qualifier would do. `shared` would no longer mean "shared".