<div dir="ltr"><div dir="ltr">On Wed, Aug 5, 2020 at 3:40 AM Timon Gehr via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 04.08.20 15:52, Sebastiaan Koppe wrote:<br>
> On Tuesday, 4 August 2020 at 12:52:01 UTC, Manu wrote:<br>
>> On Tue, Aug 4, 2020 at 5:40 PM Sebastiaan Koppe via Digitalmars-d < <br>
>> <a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
>>> There is just one thing about shared I don't understand. If I design <br>
>>> my object such that the non-shared methods are to be used <br>
>>> thread-local and the shared methods from any thread, it follows that <br>
>>> I should be able to call said shared methods from both a shared and <br>
>>> non-shared instance of that object.<br>
>><br>
>> Yes, this is a thing I talked at great length 1-2 years ago.<br>
>> If you take shared to mean "is thread-safe", then my idea was that<br>
>> not-shared -> shared implicit conversion should be possible.<br>
>> What I often do is this:<br>
>><br>
>> struct Thing<br>
>> {<br>
>>   ref shared(Thing) implSharedCast() { return *cast(shared)&this; }<br>
>>   alias implSharedCast this;<br>
>> }<br>
>><br>
>> If that were an implicit conversion, that implies a slight change of<br>
>> meaning of shared (to one that I consider immensely more useful), but <br>
>> it's<br>
>> more challenging for the compiler to prove with confidence, and there's a<br>
>> lot of resistance to this change.<br>
> <br>
> What exactly does the compiler need to prove? The restrictions are all <br>
> in place, you can only call shared methods on a shared object, and you <br>
> can only access shared members in a shared method.<br>
> ...<br>
<br>
Nope. You can access all members, but they will be treated as `shared`.<br></blockquote><div><br></div><div>"treated as `shared`"; which is, under the `-preview` merged last year some time, that they can not be read or written at all.</div><div>So you can take the address of all members, but not read or write to them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Hmm, well I guess if members themselves were also implicitly promoted to <br>
> shared that could cause havoc.<br>
<br>
Which is what the code above does, and also what Manu's "thread safe" <br>
qualifier would do. `shared` would no longer mean "shared".<br></blockquote><div><br></div><div>I described an alternative approach in my reply to you. If there is any way to inhibit an un-shared alias from the caller being propagated to the callee, maintaining a separation at the call boundary between the unshared and shared instances, then it's safe without any of my other speculative rules.</div><div></div></div></div>