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.
And I agree that it's conceivable that you could contrive a bad
program, but you can contrive a bad program with literally any
language feature!
