What To Do About Shared?

[dsimcha]

== Quote from dsimcha (dsimcha at yahoo.com)'s article
> On 3/23/2011 9:09 AM, Jason House wrote:
> > dsimcha Wrote:
> >
> >> 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.
> >
> > I didn't follow the review of std.parallelism, can you give some specific
examples?
> >
> > Users of languages look to standard libraries as a model for how to write
their own apps. I don't like your proposal and think std.parallelism should use
shared properly. I'd like to understand better what your issues with shared were.
I've done a descent amount of shared-correct code, so I'm pretty sure it's usable.
In fact, the only really nasty bug I had could have been caught if std.thread had
been shared-correct...
> I have already decided that, unless shared is drastically improved in
> ways I don't foresee (I'm not even sure exactly how, this would need to
> be discussed), I will not be making std.parallelism shared correct.

One small clarification/relaxation of this position:  I will seriously consider
making individual artifacts of std.parallelism shared correct if this can
demonstrably be done without affecting efficiency, flexibility or ease of use.
For example, certain uses of future/promise parallelism via task() are
shared-correct, marked as @safe/@trusted and documented as such.

However, I will not make shared correctness a higher priority than efficiency,
ease of use or flexibility and I will not cripple or remove artifacts that cannot
reasonably be made shared correct.