Race conditions not necessary for memory safety

[david-a-wheeler]

Many programming languages, such as Java, do not automatically prevent race conditions in memory, yet they are still considered "memory safe" programming languages.

Update the definition to match actual practice.

[nellshamrell]

Hi @david-a-wheeler!

We discussed this in today's meeting and had some ideas on how we can address this.

How would you feel if we removed data races from the "Prevents" list and instead started a separate list called "Addresses" and add data races there? We can also include some text about how some languages (such as Rust) prevent them by default, but other languages (such as Java and Go) require additional effort (such as using particular packages/libraries/standards) to prevent them?

[david-a-wheeler]

How would you feel if we removed data races from the "Prevents" list and instead started a separate list called "Addresses" and add data races there? We can also include some text about how some languages (such as Rust) prevent them by default, but other languages (such as Java and Go) require additional effort (such as using particular packages/libraries/standards) to prevent them?

That sounds better. Rust is really an outlier here. That's obviously not a bad thing for Rust, but since it's generally agreed that Java & Go are memory safe languages, asserting that they prevent all data races is too strong. It's true that Java & Go prevent certain kinds of accesses (which help address data races), but that's not the same thing.

[nellshamrell]

I've incorporated the changes we have discussed here into a new pull request #27. Closing this one, but please feel free to re-open if needed.