shared - i need it to be useful

[Stanislav Blinov]

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.

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