On Tue, Oct 16, 2018 at 3:20 AM Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On 15.10.2018 20:46, 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? > > > > Unshared becomes useless, and in turn, shared becomes useless. You can't > have unshared/shared aliasing.
What aliasing? Please show a reasonable and likely construction of the problem. I've been trying to think of it. > > 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...? > > But useless, because there is no way to ensure thread safety of reads > and writes if only one party to the shared state knows about the sharing. What? I don't understand this sentence. If a shared method is not threadsafe, then it's an implementation error. A user should expect that a shared method is threadsafe, otherwise it shouldn't be a shared method! Thread-local (ie, normal) methods are for not-threadsafe functionality.
