<div dir="ltr"><div dir="ltr">On Wed, Jun 19, 2019 at 1:24 PM Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Jun 19, 2019 at 1:15 PM Exil via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wednesday, 19 June 2019 at 03:02:30 UTC, Manu wrote:<br>
> On Wed, Jun 19, 2019 at 12:15 AM Timon Gehr via Digitalmars-d <br>
> <<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
>><br>
>> On 18.06.19 15:29, Steven Schveighoffer wrote:<br>
>> > On 6/17/19 7:46 PM, Manu wrote:<br>
>> >> Is this valid?<br>
>> >><br>
>> >> int x;<br>
>> >> void fun(scope ref shared(int) x) { ... }<br>
>> >> fun(x); // implicit promotion to shared in this case<br>
>> >><br>
>> >> This appears to promote a thread-local to shared. The <br>
>> >> problem with such promotion is that it's not valid that a <br>
>> >> thread-local AND a shared reference to the same thing can <br>
>> >> exist at the same time.<br>
>> >><br>
>> >> With scope, we can guarantee that the reference doesn't <br>
>> >> escape the<br>
>> >> callee.<br>
>> >> Since the argument is local to the calling thread, and <br>
>> >> since the<br>
>> >> calling thread can not be running other code at the same <br>
>> >> time as the<br>
>> >> call is executing, there is no way for any code to execute <br>
>> >> with a<br>
>> >> thread-local assumption while the callee makes shared <br>
>> >> assumptions.<br>
>> >><br>
>> >> I think this might be safe?<br>
>> >><br>
>> ><br>
>> > Seems like it would be safe, but what is the use case for <br>
>> > it? If you have a scope shared, which can't actually get <br>
>> > shared with anything else, what does it buy you?<br>
>> ><br>
>> > -Steve<br>
>><br>
>> He would write @system code that leaks the reference to other <br>
>> threads temporarily, but ensures those references disappear <br>
>> once the parallel part of the computation has finished. His <br>
>> use case is @safe parallel foreach without having to <br>
>> explicitly qualify the variables in the outer scope as <br>
>> `shared`:<br>
>><br>
>> void sum(){ // note: just to illustrate the concept<br>
>>      int result=0;<br>
>>      foreach(i;iota(1000).parallel){<br>
>>          static assert(typeof(result)==shared(int));<br>
>>          result.atomic!"+="(i);<br>
>>      }<br>
>>      static assert(typeof(result)==int);<br>
>>      return result;<br>
>> }<br>
><br>
> 👍<br>
><br>
> We must get here.<br>
<br>
How is it to know it is supposed to be shared though? opApply is <br>
already kind of a disaster with attributes.<br></blockquote><div><br></div><div>opApply receives a delegate; you would infer the delegate qualifier to the lambda as it already does for the loop counters from the arguments.</div><div>Ie:</div><div> opApply(scope void delegate() shared) <- infer the shared qualifier to the foreach body lambda.</div></div></div></blockquote><div><br></div><div>The delegate is effectively a prototype for the lambda, it should be used verbatim.</div></div></div>