shared - i need it to be useful

[Manu]

On Mon, Oct 15, 2018 at 2:25 PM Stanislav Blinov via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Monday, 15 October 2018 at 20:57:46 UTC, Manu wrote:
> > On Mon, Oct 15, 2018 at 1:15 PM Stanislav Blinov via
> > Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> >>
> >> On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> >>
> >> > Assuming the rules above: "can't read or write to members",
> >> > and the understanding that `shared` methods are expected to
> >> > have threadsafe implementations (because that's the whole
> >> > point), what are the risks from allowing T* -> shared(T)*
> >> > conversion?
> >> >
> >> > All the risks that I think have been identified previously
> >> > assume that you can arbitrarily modify the data. That's
> >> > insanity... assume we fix that... I think the promotion
> >> > actually becomes safe now...?
> >>
> >> You're still talking about implicit promotion?
> >
> > Absolutely. This is critical to make shared useful, and I think
> > there's a path to make it work.
> >
> >> No, it does not
> >> become safe no matter what restrictions you put on `shared`
> >> instances, because the caller of any function that takes
> >> `shared`
> >> arguments remains blissfully unaware of this promotion.
> >
> > It doesn't matter... what danger is there of distributing a
> > shared pointer? Are you concerned that someone with a shared
> > reference might call a threadsafe method? If that's an invalid
> > operation, then the method has broken it's basic agreed
> > contract.
>
> No, on the contrary. Someone with an unshared pointer may call
> unshared method or read/write data while someone else accesses it
> via `shared` interface precisely because you allow T to escape to
> shared(T). You *need* an explicit cast for this.

If a shared method is incompatible with an unshared method, your class
is broken.
Explicit casting doesn't magically implement thread-safety, it
basically just guarantees failure. What I suggest are rules that lead
to proper behaviour with respect to writing a thread-safe API.
You can write bad code with any feature in any number of ways.

I see it this way:
If your object has shared methods, then it is distinctly and
*deliberately* involved in thread-safety. You have deliberately
opted-in to writing a thread-safe object, and you must deliver on your
promise.
The un-shared API of an object that supports `shared` are not exempt
from the thread-safety commitment, they are simply the subset of the
API that may not be called from a shared context.
If your shared method is incompatible with other methods, your class
is broken, and you violate your promise.

Nobody writes methods of an object such that they don't work with each
other... methods are part of a deliberately crafted and packaged
entity. If you write a shared object, you do so deliberately, and you
buy responsibility of making sure your objects API is thread-safe.
If your object is not thread-safe, don't write shared methods.