That’s not correct. Memory safety consists of properties necessary for type safety to be upheld. Leaks alone can crash a program but can’t defeat type safety.
leaks aren't unsafe though. Things like bounds checking and aliasing guarantees are like 90% of the memory safety issues you care about, and those can be performant.
> the GC and runtime make it impossible to leak, double-free, or access out-of-bounds
This is false.
Neither C# nor Rust protect from memory leaks. There are actually some gotchas in C# that can cause memory leaks - for example, you have to be very careful about events. Memory leaks are not memory unsafe, though.
On the topic of actual memory safety - C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#, even more so, because C# doesn't require unsafe for FFI, where all bets are off. And unsafe C# is just as unsafe as unsafe Rust can be.
You have a point, but memory leaks generally aren't considered as problematic as other memory issues, such as buffer overruns and use after free. While they can cause programs to crash and degrade, they generally don't corrupt program data or lead to security vulnerabilities.
As such, people often don't include protection from memory leaks as a criterion for 'memory safety'. It's possible to explicitly leak memory in the safe subset of Rust (e.g. Box::leak). It's also possible to 'leak' memory in GC'd languages too by keeping old references around you'll never use, although this example is just arguing semantics even more.
Memory leaks are annoying and, yes, you can get them in memory safe languages.
But they are way less severe than memory corruption. Memory unsafe languages are liable to undefined behaviour, which is actively dangerous, both in theory and practice.
> That's memory safety, a valuable property but nothing to do with types.
No, it isn't. It's safety of the kind which asserts that a value of a certain type can only be operated on by suitably typed functions and operators.
The underlying memory may be safe either way: with or without the bad type punning. E.g. if a fixnum integer were treated as a character, that wouldn't be a memory problem, since they aren't heap allocated and both occupy a valid cell of the same size.
All type safety is "bit safety" at the implementation level, because in the actual semantics of the running program, objects are represented by bits, and type safety ultimately prevents bits intended to be interpreted and used one way as being used in a different way.
Memory safety is related to type safety because bits can represent pointers, and pointers can be valid or invalid, or point to objects of only so many bytes and no more.
All type checks related to pointers are providing some measure of memory safety, because if we use a non-pointer object as a pointer, or an object of one size as an object of a different size (all of which are type mismatch errors), we may end up with corruption or a crash.
unsafe memory and unsafe types are not okay if you widely claim to be memory safe. Thousands of people actually believe these lies, and companies do makes decisions on these claims. It's much more memory unsafe than Java in fact. Java recently removed the unsafe tricks, whilst rust was once safe and went more and more unsafe since.
That's not a strong analogy. Memory safety almost always involves some type of runtime checks: even memory safe languages usually (always?) have runtime checking of array bounds, for example.
So it's understood that a memory safe language will generally be composed of syntactic and semantic features which help at compile time, and runtime checks to close any remaining holes. If some particular implementation happens to have a few more things in the latter category compared than is usual, that doesn't prevent it from being "memory safe", it just makes it more awkward to use and prone to bugs.
In principle, the same distinction applies even to type safety.
That’s a dangerous line of thinking: memory safe languages can and do have memory safety bugs. There are many causes for this, from incorrect compilation (as seen here IIUC), bugs in the language runtime, concurrency problems, to unsafe language features. That doesn’t mean that there is no value in memory safe languages, they are a definite improvement. But, they are not the solution to all problems around memory safety. For example, even in Rust, which provides some of the strongest memory safely guarantees, there are memory safety issues discovered in the standard library.
But we haven't proven that a type system is the place to track memory safety. Suppose we could have an automated memory safety bug report checker that isn't in the type system?
I don't consider memory leaks a memory safety issue since all they do use use up memory and might cause failing allocations, which has to be handled one way or another regardless whenever you use dynamic memory.
1) Surely the most common source of memory corruption is bounds violations.
2) Even reconciling our disagreement on terminology, I still disagree A) that a strict phase separation is a prerequisite for types to exist at all and B) that it even makes sense to talk about "untyped" as if I couldn't just invent a type system (however complex) for proving properties of a particular language that previously had no known type system.
The simple fact of the matter is that definitions evolve over time as we learn more about our field. "Type safety" is historically valid phrase for what we now know as "memory safety". In context of the performance claims, it was quite clear what the author meant.
I never claimed all memory safe languages are type safe. But memory safety is a subset of type safety. Whether dynamic or static (though I’m much in the latter camp), memory safety is achieved through information associated with the types. Whether that’s exposed to the surface or not: Rust exposes it and is static, Haskell normally does not expose it and is also static, most modern dynamic languages are memory safe but don’t expose the associated information.
reply