Pet peeve: unwrap() should be deprecated and renamed or_panic(). More consistent with the rest of stdlib methods and appropriately scarier.

▲

wrs 31 minutes ago | parent | next [-]

That's kind of what I'm saying with the blind spot comment. The words "unwrap" and "expect" should be just as much a scary red flag as the word "panic", but for some reason it seems a lot of people don't see them that way.

▲

echelon an hour ago | parent | prev [-]

A lot of stuff should be done about the awful unwrap family of methods.

A few ideas:

- It should not compile in production Rust code

- It should only be usable within unsafe blocks

- It should require explicit "safe" annotation from the engineer. Though this is subject to drift and become erroneous.

- It should be possible to ban the use of unsafe in dependencies and transitive dependencies within Cargo.

▲

kibwen an hour ago | parent [-]

The `unsafe` keyword means something specific in Rust, and panicking isn't unsafe by Rust's definition. Sometimes avoiding partial functions just isn't feasible, and an unwrap (or whatever you want to call the method) is a way of providing a (runtime-checked) proof to the compiler that the function is actually total.

▲

echelon an hour ago | parent [-]

Panics should be explicit, not implicit.

unwrap() should effectively work as a Result<> where the user must manually invoke a panic in the failure branch. Make special syntax if a match and panic is too much boilerplate.

This is like an implicit null pointer exception that cannot be statically guarded against.

I want a way to statically block any crates doing this from my dependency chain.

	▲	bigstrat2003 40 minutes ago \| parent \| next [-]
		unwrap is explicit.
	▲	wrs 32 minutes ago \| parent \| prev [-]
		Not sure what you're saying with the "work as a Result<>" part...unwrap is a method on Result. I think you're just saying the unwrap/expect methods should be eliminated?