[pjmlp]

> Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary?

They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system.

While in the languages I mentioned, unsafe constructs are related any operation that might lead to memory corruption, some Rust devs are using it for anything they assume isn't logical safe.

So you then get talks like the Session Types one at ICFP, that uses unsafe to control functions being called outside the protocol Traits that are being defined.

Which lead to discussions like this one:

https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136...

[smosher_]

> They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system.

That doesn't sound like abuse to me, as long as the exposed interface remains safe.

> some Rust devs are using it for anything they assume isn't logical safe.

That sounds like an objection to the scope of what Rust defines as safe. Unless you mean to imply there are reasonable, Rust-safe ways to rewrite the transgressions. In the former case I have to disagree. It would be nice if we could prove more. But you can't prove everything.

I haven't seen the ICFP talk but I might watch it later if you can link to a video. I've skimmed that discussion before but you will need to point out your objections—IMO it is great that Rust devs are having that discussion.

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

[kinghajj]

So your objection is to how certain users (notably not the core dev team) utilize "unsafe", now with the language itself. It seems like the easiest way to mitigate this is with better documentation; surely, those other languages' equivalents of "unsafe" could also have been abused similarly, no?

[pjmlp]

No, because on those languages unsafe is only related to memory integrity.