[pjmlp]

My objection is that I see unsafe just for memory integrity.

For everything else something like contracts should be used, from my point of view.

As for voicing my objections to the Rust community, being a language geek is one of my hobbies, but it doesn't mean I will ever use those languages at work.

So I would only contribute noise to the discussions, which why I eventually moved away from Go and D forum discussions as well.

My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on.

[smosher_]

> 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!

[dbaupp]

> 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.

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.

[steveklabnik]

To be clear, we on the Rust team see 'unsafe' as being strictly about memory safety as well, and have actively fought against using it as a general "pay attention here" kind of annotation.

Eventually, effects would be nice to mark other kinds of "here be dragons" as well, but for now, unsafe == possible memory unsafety.

[smosher_]

If you read the comment you'll see that I'm talking about different interpretations of memory safety. You can't just decide what it means in Rust applies to all languages, or that everyone knows what you mean.

I was trying hard to have a conversation while avoiding arguing about semantics, so thanks for that.