On Thursday, 13 January 2022 at 21:13:11 UTC, jmh530 wrote:
>On Thursday, 13 January 2022 at 20:58:25 UTC, H. S. Teoh wrote:
>[snip]
I'm not 100% sure why .parallel is @system, but I suspect it's because of potential issues with race conditions, since it does not prevent you from writing to the same local variable from multiple threads. If pointers are updated this way, it could lead to memory corruption problems.
T
Could it be made @safe when used with const/immutable variables?
For some data to be @safe-ly accessible across threads it must have no "unshared aliasing", meaning that shared(const(T))
and immutable(T)
are ok, but simply T
and const(T)
are not.
The reason why the .parallel
example above was not safe, is because the body of the foreach was passed as a delegate to the ParallelForeach.opApply
and the problem is that delegates can access unshared mutable data through their closure. If the @safe-ty holes regarding delegates are closed, presumably we could add a ParallelForeach.opApply
overload that took a @safe
delegate and then the whole main
function could be marked as @safe
.
I think back when the module was under active development, the authors did carefully consider the @safe-ty aspects, as they have written code that conditionally enables some function overloads to be @trusted
, depending on the parameters they receive. But in the end it was the best they could given the state of the language at the time. Most likely the situation has improved sufficiently that more the of the API could be made (at least conditionally) @safe.
You can check the various comments explaining the situation: