I wish all qualifiers were revisited with an eye for simplification

[Manu]

On Tue, Aug 4, 2020 at 11:55 PM Sebastiaan Koppe via Digitalmars-d <
digitalmars-d at puremagic.com> 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?


It would be ideal if the compiler could validate that the un-shared methods
are safe with respect to any shared methods.
If a shared (ie, 'thread-safe') method were called in parallel to an
un-shared method as is possible if the implicit conversion was allowed,
then it is necessary that un-shared methods need to be tolerant of their
'thread-safe' API being called at any time. That's the change in meaning
which is highly dangerous without some serious tooling. Essentially, adding
a shared method to an object applies a contract to all other NOT-shared
methods, and that doesn't feel good; "touching this here affects those
other things"... it will be super hard to audit.

Technology that looks like ThreadSanitizer might help, but it gets more
tricky again when UFCS is used instead of member functions; those
associations are harder to track.

I think that idea is doomed, and more recently I'm thinking about ways to
prevent sneaking un-shared aliases across the conversion boundary... but I
don't know how to achieve that without some sort of aliasing rules which
seem unlikely.

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

Ummmm no, under any of my proposals, you can't access shared members in a
shared method... a shared method's `this` pointer is shared, which means
all members are shared, and shared data may not be read or written at
all... shared methods have no @safe access to members. They can only call
other shared methods @safe-ly.

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

Members inherit the qualifier of methods... in a shared method, members are
shared, which means you can't read or write them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200805/45dd1c92/attachment-0001.htm>