std.concurrency and efficient returns

[dsimcha]

== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> dsimcha Wrote:
> > == 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?
> Ideally, the parallelism should be both invisible to the user and automatically
safe.  That isn't a realistic goal though, so a balance must be found between
performance and safety.  I'd venture to say the "here be dragons" approach is
correct for the most part though.  If too much performance is traded away for
safety, no one will use it.

My other major concern is that if too much convenience (in simple cases where the
programmer does know what he/she is doing even if the guarantees aren't statically
checkable) is traded for safety (i.e. by requiring stuff to be cast explicitly to
shared in lots of places), the API will become almost unusable.