You check and unpack once, then the rest of the "positive" codepath can use the reference without fearing null.

I fail to see how Rust would offer twice as many ways to shoot yourself in the foot ; this is a rather safe and picky language.

▲

5701652400 2 hours ago | parent [-]

true, "non-nil pointers"/references will help here to avoid nil checks.

also true, if you have optional you still need to unpack it somwhere, and your nil checks become unpacking statements. delayed conditionals and delegation to callsites far from offending code (what author says) is still present.

and if you also have pointers, then you can do Optional<Pointer>.. and now you have to option unpakcing + nil checks. 2x more problems.

	▲	tialaramex 9 minutes ago \| parent [-]
		If you have an actual pointer type mut P then Option<mut P> might be None or it might be Some(null_pointer) or Some(other_pointer) that's not 2x more problems it's just a representation of a more complicated scenario - we may or may not have a pointer and, if we do have a pointer that might be null. We'd presumably have done this because we need to distinguish those cases. If you actually mean Option<NonNull<P>> you should write that, now we're saying this is either a non-null pointer or it's nothing. Often though you want Option<&P> either a reference or nothing, or you actually did mean a raw pointer *mut P and you're going to handle scenarios where it is null or whatever.