On Mon, Oct 15, 2018 at 2:25 PM Stanislav Blinov via Digitalmars-d <digitalmars-d@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@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.
