[Matthias247]

I think people refer to memory safe in general as "not being able to override memory that is not currently owned by a referred object in the program" - which certainly applies to all GCed languages.

It's definitely true that this does not imply thread-safe, and the ability to prevent the mess up the consistency of valid objects.

[arghwhat]

> I think people refer to memory safe in general as "not being able to override memory that is not currently owned by a referred object in the program" - which certainly applies to all GCed languages.

This is absolutely false. Race conditions in native structures can very easily invalidate any memory safety guarantees provided by the language, causing issues such as buffer overflows.

In other words, the presence of any memory unsafe operation leads to a total and immediate loss of all memory safety.

See for example how races in Go can lead to type confusion for interface types (fat pointers) through store tearing (non-atomic writes): https://research.swtch.com/gorace or https://groups.google.com/forum/#!msg/golang-dev/mXjFejQ5A3Q...

The former has a detailed explanation, the latter has a code example that shows more clearly what the technique can be used to do (cast a struct A to unrelated struct B with different length, thus allowing out-of-bounds reads/writes).

If on the other hand you were just saying that these languages are just called memory safe, even though they aren't, then yes. That's what I said.