Temporally safe by default

[Sebastiaan Koppe]

On Monday, 8 April 2024 at 19:59:55 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
>
> On 09/04/2024 7:43 AM, Dukc wrote:
>> On Friday, 5 April 2024 at 10:34:24 UTC, Richard (Rikki) 
>> Andrew Cattermole wrote:
>>> ``shared`` does not offer any guarantees to references, how 
>>> many there are, on what threads its on. None of it. Its fully 
>>> up to the programmer to void it if they chose to do so in 
>>> normal ``@safe`` code.
>> 
>> My impression is you can't do that, unless the data structure 
>> you're using is flawed (well `dataStruct.tupleof` of the works 
>> to bypass `@safe`ty but I don't think it's relevant since it 
>> probably needs to be fixed anyway). Pseudocode example?
>
> ```d
> void thread1() {
> 	shared(Type) var = new shared Type;
> 	sendToThread2(var);
>
> 	for(;;) {
> 		// I know about var!
> 	}
> }
>
> void sentToThread2(shared(Type) var) {
> 	thread2(var);
> }
>
> void thread2(shared(Type) var) {
> 	for(;;) {
> 		// I know about var!
> 	}
> }
> ```
>
> The data structure is entirely irrelevant.
>
> Shared provided no guarantees to stop this.
>
> No library features can stop it either, unless you want to 
> check ref counts (which won't work cos ya know graphs).
>
> You could make it temporally safe with the help of locking, 
> yes. But shared didn't contribute towards that in any way shape 
> or form.

I don't think this has much to do with shared. You can get in 
similar situations on a single thread, just not in parallel.

Solving it requires tracking lifetimes, independent of whether 
that is across threads.

D has very little in the way of an answer here. It has the GC for 
auto lifetime, smart pointers and then shoot-in-the-foot manual 
memory management.

Well, and there is scope with dip1000 of course, which works 
surprisingly well but requires phrasing things in a more 
structured manner.

Curious to what you have been cooking.