shared - i need it to be useful

[Stanislav Blinov]

On Thursday, 18 October 2018 at 19:04:58 UTC, Erik van Velzen 
wrote:
> On Thursday, 18 October 2018 at 17:47:29 UTC, Stanislav Blinov 
> wrote:
>> On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves 
>> 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?
>>>
>>> int i;
>>> tid.send(&i);
>>> ++i;  // oops, data race
>>
>> Doesn't work. No matter what you show Manu or Simen here they 
>> think it's just a bad contrived example. You can't sway them 
>> by the fact that the compiler currently *prevents* this from 
>> happening.
>
> Manu said clearly that the receiving thread won't be able to 
> read or write the pointer.

Yes it will, by casting `shared` away. *Just like* his proposed 
"wrap everything into" struct will. There's exactly no difference.

> Because int or int* does not have threadsafe member functions.

int doesn't have any member functions. Or it can have as many as 
you like per UFCS. Same goes for structs. Because "methods" are 
just free functions in disguise, so that whole distinction in 
Manu's proposal is a weaksauce convention at best.

> You can still disagree on the merits, but so far it has been 
> demonstrated as a sound idea.

No, it hasn't been.