shared - i need it to be useful

[Stanislav Blinov]

On Friday, 19 October 2018 at 00:36:11 UTC, Timon Gehr wrote:
> On 19.10.18 02:29, Stanislav Blinov wrote:
>> On Thursday, 18 October 2018 at 23:47:56 UTC, Timon Gehr wrote:
>> 
>>> I'm pretty sure you will have to allow operations on shared 
>>> local variables. Otherwise, how are you ever going to use a 
>>> shared(C)? You can't even call a shared method on it because 
>>> it involves reading the reference.
>> 
>> Because you can't really "share" C (e.g. by value). You share 
>> a C*, or, rather a shared(C)*.
>
> (Here, I intended C to be a class, if that was unclear.)

In that case, it's already a pointer, and the only real issue is 
the interaction with GC, which I mentioned before *needs* to be 
addressed. And that is only when C was allocated by GC.

>> The pointer itself, which you own, isn't shared at all, and 
>> shouldn't be: it's your own reference to shared data. You can 
>> read and write that pointer all you want. What you must not be 
>> able to do is read and write *c.
>> ...
>
> Presumably you could have a local variable shared(C) c, then 
> take its address &c and send it to a thread which will be 
> terminated before the scope of the local variable ends.

I assume you mean *after*, because if that thread terminates 
before there's no problem.

> So, basically, the lack of tail-shared is an issue.

Well, not exactly. Irrespective of Manu's proposal, it's just 
inherent in D: sharing implies escaping, there's really no way 
around it. Provisions must be made in DIP1000 and in the language 
in general. However, that is a good point *against* implicit 
conversions, let alone @safe ones.