@jplatte It’s essentially the same phenomenon, but triggered in a different way.

@tczajka Your example is indeed much clearer.

Working case:

A has an unknown type → A = B → B has a known type → compiles successfully

Failing case:

A has an unknown type → access A.field → A = B → B has a known type → type inference fails

Even though the IDE (e.g. Rust…

Trying to follow the arguments that unsafe should be for memory safety only: then why are some methods in std marked unsafe, like str:from_utf8_unchecked or char::from_u32_unchecked?

Especially the latter is documented as " This function is unsafe, as it may construct invalid char values." ... so? AFAICT an invalid char by itself value wouldn't be memory unsafe. As it takes a u32…

Sorry for the essay I couldn't figure out a way to condense it without losing info.

TLDR: unsafe is useful because it is rare, and making it less rare by applying it to general invariants/preconditions doesn't actually help ensure correctness.

Vorpal:

There is a lot of Rust code at this point. I get 6.7 million results for unwrap and 18.2k results for unwrap_unchecked (filtered on…

I've been following this thread closely for a few days. I feel like there's some pushback mostly from people closer to the compiler, but as a long-time Rust dev working on libraries I'd like to express my full support for the position defended by @tczajka. His examples about the Prime or TwoDigit new-types are extremely illustrative of the issues I'm facing day-to-day.

The core problem is…

Well, something like `NonZero` by @tczajka would benefit from reads being unsafe, as `get` will contain unsafe code.