I wish all qualifiers were revisited with an eye for simplification

[Manu]

On Wed, Aug 5, 2020 at 3:40 AM Timon Gehr via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> 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`.
>

"treated as `shared`"; which is, under the `-preview` merged last year some
time, that they can not be read or written at all.
So you can take the address of all members, but not read or write to them.

> 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".
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200805/63104cff/attachment.htm>