https://issues.dlang.org/show_bug.cgi?id=19984
--- Comment #3 from Manu <[email protected]> --- That's a pretty disappointing solution, because it leaves the massive un-safety that I'm trying to address in place. In your example you can use `_.s` from the capture, but you can also still refer to `s`, which is the obvious thing to do, and it's a race waiting to be typed. It's unreasonable for the interior of the for loop to have not-shared references to outer values. Basically, I'm proposing that since the opApply implements the loop, and it defines what is safe to do from inside the loop body, an effective way to assert that function's specification of what is valid inner-loop code, is to infer the function attributed from the opApply function onto the lambda that it receives. an `opApply(...) shared` method that inferred the `shared` attribute onto the loop body lambda feels like a really appropriate way to achieve this outcome. It might also be reasonable that some loop body may not write to outer scope, and it could infer `const` the same way, etc. --
