|
|
|
|
|
|
by smosher_
3921 days ago
|
|
|
> My objection is that I see unsafe just for memory integrity. Either you think this way because of a sense of orthodoxy or because you think memory safety is important in a way the other kinds of safety aren't. I disagree, especially since "memory safety" may or may not imply protection against aliasing of mutable data. Those nuances I like about Rust probably wouldn't exist without the broader scope of safety concerns. > As for voicing my objections to the Rust community, About the discussion you linked? I meant to me, in the service of explaining your objections. > My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on. Well, that was important information. Thanks for making the time to share! |
|
|
Memory safety is more fundamental than most other sorts of correctness: it is a necessary (but not sufficient) condition for them. If you can't assume memory safety, you have no assurances about any other invariants, because any piece of data can be modified/outdated/invalidated at any time in the program's execution. (This is especially bad if the compiler will itself assume that memory safety can never happen, and use this undefined behaviour to optimise the program in unintended ways.)
I'm fairly sure that some definitions of memory safety that works for Rust are "there are no use-after-frees" or "the language is type-safe"; all 'other' problems with memory safety (iterator invalidation, data races, etc.) can be used to violate those and hence need to be outlawed. I'm not sure there's that much wiggle room for what memory safety means, at least in broad terms. In any case, aliasing of mutable data can definitely lead to memory unsafety, and is hence covered/controlled by Rust's guarantees. In some ways, it is really the fundamental cause of memory unsafety: remove/control either "aliasing" (e.g. Rust, many GC'd languages) or "mutable" (e.g. Haskell) and you've got memory safety.
Also, Rust definitely doesn't only try to help the programmer with memory safety, it's just memory safety (and hence type safety) is the form that has hard guarantees. Other forms are generally handled by "lints"/warnings or by building libraries on top of the type system.