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.
