== Quote from Sean Kelly (s...@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.
