Very limited shared promotion

[Timon Gehr]

On 18.06.19 15:29, Steven Schveighoffer wrote:
> On 6/17/19 7:46 PM, Manu wrote:
>> Is this valid?
>>
>> int x;
>> void fun(scope ref shared(int) x) { ... }
>> fun(x); // implicit promotion to shared in this case
>>
>> This appears to promote a thread-local to shared. The problem with
>> such promotion is that it's not valid that a thread-local AND a shared
>> reference to the same thing can exist at the same time.
>>
>> With scope, we can guarantee that the reference doesn't escape the 
>> callee.
>> Since the argument is local to the calling thread, and since the
>> calling thread can not be running other code at the same time as the
>> call is executing, there is no way for any code to execute with a
>> thread-local assumption while the callee makes shared assumptions.
>>
>> I think this might be safe?
>>
> 
> Seems like it would be safe, but what is the use case for it? If you 
> have a scope shared, which can't actually get shared with anything else, 
> what does it buy you?
> 
> -Steve

He would write @system code that leaks the reference to other threads 
temporarily, but ensures those references disappear once the parallel 
part of the computation has finished. His use case is @safe parallel 
foreach without having to explicitly qualify the variables in the outer 
scope as `shared`:

void sum(){ // note: just to illustrate the concept
     int result=0;
     foreach(i;iota(1000).parallel){
         static assert(typeof(result)==shared(int));
         result.atomic!"+="(i);
     }
     static assert(typeof(result)==int);
     return result;
}