Pitfalls of Safe Rust

No, the Rust community almost universally understands "safe" as referring to memory safety, as per Rust's documentation, and especially the unsafe book, aka Rustonomicon [1]. In that regard, Safe Rust is safe, Unsafe Rust is unsafe, and C++ is also unsafe. I don't think anyone is saying "C++ is all unsafe."

You might be talking about "correct", and that's true, Rust generally favors correctness more than most other languages (e.g. Rust being obstinate about turning a byte array into a file path, because not all file paths are made of byte arrays, or e.g. the myriad string types to denote their semantics).

[1] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

The problem with the title is that the phrase "pitfalls of safe rust" implies that these pitfalls are unique to, or made worse by, safe rust. But they aren't. They are challenges in any programming language, which are no worse in rust than elsewhere.

It's like if I wrote an article "pitfalls of Kevlar vests" which talked about how they don't protect you from being shot in the head. It's technically correct, but misleading.

> This regularly drives C++ programmers mad

I thought the C++ language did that.

Safe Rust code doesn't have accidental remote code execution. C++ often does. C++ people need to stop pretending that "safety" is some nebulous and ill-defined thing. Everyone, even C++ people, shows perfectly damn well what it means. C++ people are just miffed that Rust built it while they slept.

If english had static checks this kind of runtime pedantry would be unnecessary. Sometimes it's nice to devote part of your brain to productivity rather than checking coherence.

Another limitation I face is the impossibility of using `usize::from(n)` in `const` context.

Yeah, but I meant a method that would take a custom prefix, like join does now. (In the hypothetical situation where join had different semantics.)

I have been following rust very closely since 2013.

As Rust is both evolving and spreading wide, we; the programmers, users of Rust; are also leveling up in how we approach correctness and design with it.

Maybe the next evolution will be something like Haskell but fast like Rust is fast like C without the pain of C++.

But it takes a while for the world to catch up, and for everybody to explore and find ways to work with or around the abstractions that helps with correctness.

It's a bit like the evolution from a pointer to some malloc memory, then the shared/unique pointer of C++, to the fully safe box/(a)rc of Rust.

It might be obvious today how much more efficient it is programming with those abstractions.

I see some similarities with functional programming that still seems so niche. Even though the enlighteneds swears by it. And now we actually seem to be slowly merging the best parts of functional and imperative together somehow.

So maybe we are actually evolving programming as a species. And Rust happens to be one of the best scaffold at this point in history.

Thank you for reading my essay.

There is some movement towards deprecating "as", and lints that will recommend using alternatives when possible, but there are a couple of cases, such as intentional truncation, where there isn't a stable alternative yet.

Regarding the not-NAN float type, there was actually a proposal for it which was shot down: https://github.com/rust-lang/libs-team/issues/238.

I don't remember every argument in there but it seemed that there are good reasons not to add it unlike a NonZero integer type which seems to have no real downsides.

The other option would be to change how floating point works. IEEE specifies operations, not names, so it would be totally valid to have <= on floats be a total order (using integer cpu instructions), and make a function called IEEEAreIdiotsWhoThinkThisIsFloatingPointLessThan which is the partial order that sucks.

Some of these don't strike me as particularly pragmatic. E.g. are overflow checks really that expensive, given that it's a well-known footgun that is often exploitable? Sure, you don't want, say, 10% overhead in your number-crunching codec or whatever, but surely it's better to have those cases opt in for better perf as needed, as opposed to a default behavior that silently produces invalid results?

> guaranteed-not-NaN-nor-inf

Nor negative zero

I'm struggling to see how you would implement narrowing conversion in a way that is harder for programmers to misuse when they aren't being mindful, while also being pleasant to use when you really do want to just drop higher bits. Like, you could conceivably have something like a "try_narrow" trait which wraps the truncated value inside an Err when it doesn't fit, and it would probably be harder to accidentally misuse, but that's also really cumbersome to use when you are trying to truncate things.

It's useful to have something that does the job of "as", but I dislike how the most dangerous tool for type conversions has the nicest syntax.

Most of the time I want the behavior of ".try_into().unwrap()" (with the compiler optimizing the checks away if it's always safe) or would even prefer a version that only works if the conversion is safe and lossless (something I can reason about right now, but want to ensure even after refactorings). The latter is really hard to achieve, and ".try_into.unwrap()" is 20 characters where "as" is 2. Not a big deal to type with autocomplete, but a lot of visual clutter.

The question is not whether the language should include such a facility, but whether 'as' should be the syntax for it. 'as' is better than the auto conversions of C but it's still extremely obscure. It would be better to have some kind of explicit operator marking this kind of possibly unintended modulo conversion. Rust will gain safe transmute operations in the near future so that will perhaps be a chance to revise this whole area as well.

Yeah, they're so common they've become a part of our culture when it comes to interacting with computers.

Arithmetic overflows have become the punchline of video game exploits.

Unsigned underflow is also one of the most dangerous types. You go from one of the smallest values to one of the biggest values.

On the other hand, there’s a solid use case for underflow.

For any arithmetic expression that involves only + - * operators and equally-sized machine words, two's complement will actually yield a "correct" result. It's just that the given result might be indicating a different range than you expect.

This is something that's always bugged me because, yes, this is a real problem that produces real bugs. But at the same time if you really care about this issue then every arithmetic operation is unsafe and there is never a time you should use them without overflow checks. Sometimes you can know something won't overflow but outside of some niche type systems you can't really prove it to the compiler to elide the check in a way that is safe against code modifications— i.e. if someone edits code that breaks the assumption we needed to know it won't overflow it will err.

But at the same time in real code in the real world you just do the maths, throw caution to the wind, and if it overflows and produces a bug you just fix it there. It's not worth the performance hit and your fellow developers will call you mad if you try to have a whole codebase with only checked maths.

If you saturate you almost never ever want to use the result. You need to check and if it saturates do something else.