[foldr]

I'm 100% sure that I understand what safe means in this context. All modern GCed languages are memory safe and will not access invalid memory regions unless you use specifically unsafe features.

> One common example is modifying a vector element by reference. If you grab a reference to an item, push something else to the vector, then try to access through that reference, the vector may have re allocated during the push and you're either no longer looking at valid memory because it's been freed, or you're looking at a stale copy of the element.

There aren't that many languages which both use GC and allow you to take references to elements of a vector. Go would be one example. I can assure you that you cannot access undefined memory regions by doing this in Go. (What would happen is that the original allocation backing the vector would be retained in addition to the new allocation.)

>If no code handles the nil exception for example then it's no better than crashing as you would in C

C programs are not guaranteed to crash when a pointer has an invalid value. Dereferencing a NULL pointer will reliably cause a crash if you're running the code on top of a modern general purpose operating system with memory protection, but invalid pointers (which don't necessarily have to be NULL) have the potential to access arbitrary memory regions without raising any kind of error.

[ngrilly]

> I can assure you that you cannot access undefined memory regions by doing this in Go.

Current implementation of slices and interfaces in Go is not memory safe in presence of data races:

https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...

[foldr]

This is the kind of edge case you can find in lots of languages, including Rust (which has plenty of past and present soundness bugs).

[preseinger]

Data races are violations of the memory model; of course any code which produces data races cannot be understood as memory safe?

[ngrilly]

As far as I remember, some languages like Java are memory safe even if the code produces data races. That means you can't have a reference to a value supposed to be of type A being actually of type B.

[int_19h]

That's part of what the Rust borrow checker does for you: tracking who owns what and enforcing single ownership makes data races that much harder to cause.

[Shikadi]

Turns out I'm the one who forgot what memory safety is o.o I think the part that makes rust's memory safety special is that it also lacks garbage collection