std.concurrency and efficient returns

[dsimcha]

== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> I wouldn't worry--the modules in core will always provide the low-level control
that you're looking for.  As for message passing, I think it should be the default
choice but not the only choice.  Things like futures are a reasonable addition to
Phobos as well.

How explicit do we want to make inter-thread sharing when using a
futures/tasks/parallel foreach library?  This question may be a result of the fact
that I (still) don't understand what shared is supposed to do, but do we want to
force all data to be shared/cast to shared even under a futures/tasks/parallel
foreach model, or do we want to bypass the shared system entirely and simply stick
to old-fashioned "here be dragons" when doing future/task/parallel foreach-based
multithreading?

My personal opinion (which may change if I understand shared better) is that "here
be dragons" is the way to go.  Futures/tasks/parallel foreach are meant for
parallelizing small hotspots, where the programmer generally knows implicitly what
assumptions are being made, and generally revolve completely around shared memory
and, where necessary, explicit locking.  Forcing things to be cast to shared left,
right and center would simply be an annoying piece of syntactic salt that doesn't
actually solve any problems in these cases.  (It would also completely destroy the
nice, clean interface of the module I've created for task/future/parallel foreach.)

I think Phobos's std.parallelism should just come with a big "here be dragons"
sign and that's about it as far as safety/use of shared/etc.