Some discussions about std.parallelism have prompted an examination of
how far D's guarantees against low level data races should extend and
how safety and practicality should be balanced. On the one hand,
coarse-grained multithreading with hard guarantees against low-level
races is a great thing if it's flexible enough to do what you need it to.
On the other hand, not everything is implementable (at least not
efficiently or easily) in such a paradigm. D is a systems language and
should not force people who want unchecked shared state multithreading
to either do without it for fight the type system every inch of the way
(by casting all over the place) to get it.
I've come up with the following proposal, which is implicitly used in
the design of std.parallelism, but which I think should be made explicit.
1. All @safe code must be statically checkable and provably free from
low level data races provided that all @trusted code it calls is
correctly implemented. It may not cast away shared, etc.
2. All @trusted code must guarantee to its clients that calling such
code from @safe code will not result in low level data races.
3. All modules that deal with multithreading must document either that:
a. They will use the type system to guarantee that low-level data
races can't happen.
b. They will share state freely.
c. They will mostly share state freely, but will make guarantees
about some specific subset.
std.concurrency would be in category a. core.thread would be in
category b. std.parallelism would be in category c.
All code that only uses modules from category a, does not cast away
shared and does not use __gshared variables can be guaranteed free from
low level data races even if it is not @safe.
If you want hard guarantees about low level data races, these can be
achieved with a very small amount of discipline: Only use modules from
category a or only use @safe code. This is easily checkable. Using
modules from category b or modules from category c in non-@safe code
should be considered equivalent to casting away shared: You may do so,
but you're on your own when it comes to thread safety and you may not do
it in @safe code.
