> It should be limited to use in `unsafe` blocks.

That would be a fairly significant expansion of what `unsafe` means in Rust, to put it lightly. Not to mention that I think doing so would not really accomplish anything; marking unwrap() `unsafe` would not "surface `unwrap` usage" or "make any guarantees", as it's perfectly fine for safe functions to contain `unsafe` blocks with zero indication of such in the function signature and.

▲

echelon 3 hours ago | parent [-]

> fairly significant expansion of what `unsafe` means in Rust

I want an expansion of panic free behavior. We'll never get all the way there due to allocations etc., but this is the class of error the language is intended to fix.

This turned into a null pointer, which is exactly what Rust is supposed to quench.

I'll go as far as saying I would like to statically guarantee none of my dependencies use the unwrap() methods. We should be able to design libraries that provably avoid panics to the greatest extent possible.

Unwrap is an easy loss on a technicality.

	▲	aw1621107 2 hours ago \| parent [-]
		> I want an expansion of panic free behavior. Sure, and I'd hardly be one to disagree that a first-party method to guarantee no panics would be nice, but marking unwrap() `unsafe` is definitely not an effective way to go about it. > but this is the class of error the language is intended to fix. Is it? I certainly don't see any memory safety problems here. > This turned into a null pointer, which is exactly what Rust is supposed to quench. There's some subtlety here - Rust is intended to eliminate UB due to null pointer dereferences. I don't think Rust was ever intended to eliminate panics. A panic may still be undesirable in some circumstances, but a panic is not the same thing as unrestricted UB. > We should be able to design libraries that provably avoid panics to the greatest extent possible. Yes, this would be nice indeed. But again, marking unwrap() `unsafe` is not an effective way to do so. dtolnay's no_panic is the best we have right now IIRC, and there are some prover-style tools in an experimental stage which can accomplish something similar. I don't think either of those are polished enough for first-party adoption, though.