Some missing things in the current threading implementation

[dsimcha]

== Quote from Sönke_Ludwig (ludwig at informatik.uni-luebeck.de)'s
> If the language allows for creating an array, splitting it and
> processing the chunks in separate threads - and that without any cast in
> the user part of the code + the user code is safely checked - I think
> everything would be fine. Of course a full solution in the language
> would be ideal, but my worries are more that in general you have to
> leave the checked part of the type system so often, that all that type
> checking might be completely useless as only the most simple threading
> constructs are checked. In that way a library solution that hides the
> casts and still guarantees (almost) safe behaviour would already be a
> huge step forward.
> Maybe a UniqeArray(T) type that is library checked and that you can pass
> through spawn() would be a sufficient solution to at least this problem.
> It could make sure that T is POD and that only operations are allowed
> that still guarantee uniqueness of the elements.

I thought about making a safe std.parallelism.map().  (There's currently an unsafe
one.)   It's do-able under some limited circumstances but there are a few roadblocks:

1.  The array passed in would have to be immutable, which also would make it very
difficult to make map() work on generic ranges.

2.  The return value of the mapping function would not be allowed to have unshared
aliasing.

3.  No user-supplied buffers for writing the result to.

A safe parallel foreach just Ain't Gonna Work (TM) because the whole point of
foreach is that it takes a delegate and everything reachable from the stack frame
is visible in all worker threads.