On Wed, 22 Sep 2010 15:08:26 -0400, Don <nos...@nospam.com> wrote:
Robert Jacques wrote:
On Wed, 22 Sep 2010 11:44:00 -0400, Don <nos...@nospam.com> wrote:
Robert Jacques wrote:
On Wed, 22 Sep 2010 07:54:26 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2010-09-22 01:26:01 -0400, "Robert Jacques" <sandf...@jhu.edu>
said:
So removing the concurrency safety from pure would greatly expand
the number of pure functions, however, automatic parallelism would
be lost.
Don clearly mentioned that this is not lost. Basically, for safe
parallelism what you need is a function that has a) pure and b) no
mutable reference parameter. Both are easily checkable at compile
time, you'd just need to change your test for pure for a test that
also checks the arguments.
What is lost is my ability to declare a function does x in the
signature and for the compiler to check that. I really want to know
if code monkey A changed some type's implementation to be thread
unsafe, because detecting and tracking down a loss of performance due
to loss of automatic parallelism is devilish.
No, you haven't lost that at all. Any function marked as pure still
has no access to any state, other than what is provided by its
parameters. It is still thread-safe.
No, it isn't. A strongly-pure function is thread safe, but a
weakly-pure function isn't. Since strong/weak is automatically
determined by the compiler, a function's strength can switch due to
long distance code changes.
This is completely incorrect. It can only change strength if its
signature changes.
Hypothetical counter-case
struct S
{
version(stronglypure)
string s;
else
char[] s;
}
pure foo(S s); // changes strength depending on S' contents
-Steve
