Add unsafe Option::unwrap_unchecked()

[dschatzberg]

No description provided.

[lilyball]

Have you verified that the compiler does in fact optimize it away?

[dschatzberg]

This is dependent on a lot of different cases. If I build a library as follows:

#![feature(core)]

use std::intrinsics;

pub fn my_unwrap(o: Option<i32>) -> i32 {
    match o {
        Some(v) => v,
        None => panic!("panic")
    }
}

pub unsafe fn my_unwrap_unsafe(o: Option<i32>) -> i32 {
    match o {
        Some(v) => v,
        None => intrinsics::unreachable()
    }
}


$ rustc -O --crate-type=lib unwrap.rs
$ objdump -d libunwrap.rlib
0000000000000000 <_ZN16my_unwrap_unsafe20h8f4545557bc4e296MaaE>:
   0:   48 c1 ef 20             shr    $0x20,%rdi
   4:   89 f8                   mov    %edi,%eax
   6:   c3                      retq   

You can see no conditionals in the unwrap_unsafe asm. Further testing on the actual standard library implementation would be needed to confirm, but at least one method of implementing it seems to work as I expect.

[seanmonstar]

Other possible alternative: If we added branch weights, such as llvm.expect, we could expect the Some case, which would help the compiler to make it the fast case.

[reem]

One benefit of adding this is that it would allow stable users to (unsafely) express unreachability without needing the unstable intrinsics API.

[Gankra]

I've definitely wanted this before for expressing the invariants in data structures (stuff like "if I'm at this point in the program the root/parent must not be null"). Not for any particularly profiled reason, though. Just a vague sense of "I don't like having the code think it can panic here".

However if the intrinsic was properly exposed I believe this could just be written as foo.unwrap_or_else(intrinsics::unreachable). This is easy for someone to make a function/extension trait for if they want better semantics. As such it seems like a very minor ergonomic benefit to expose a dedicated method for.

[brson]

I'm interested to see specific code in std where this optimization helps.

[dschatzberg]

@brson How is what you're asking different from what is already in the RFC? The example I provided is from std.

[tbu-]

You can also use .unwrap_or_else(|| intrinsics::unreachable())

[SimonSapin]

As far as I can tell this can be done in a library outside of std, with the only downside that you’d have to use a trait where you use it.

[tbu-]

@SimonSapin That can be said for all things in the standard library. :)

[bluss]

I actually think the explicit match is desireable. It would be much better if we suggested this pattern:

let inner_value = match opt {
    Some(x) => x,
    None => debug_assert_unreachable("This is a bug"),
};

I.e. we encourage the user to check their assumptions in the code with debug assertions, this particular macro or function after reem's model would behave like debug_assert!() in debug builds and be the unreachable intrinsic in release builds.

[tbu-]

@bluss One could make a functions which does exactly this to encourage the pattern. :)

[alexcrichton]

This RFC is now entering the final-comment-period for one week.

[alexcrichton]

I personally see this as a minor convenience that doesn't necessarily pull its weight as a method, I'd prefer either @tbu-'s or @bluss's suggestion which would involve stabilizing this form of "unsafe unreachable" in a different manner.

[SimonSapin]

I'd prefer either @tbu-'s or @bluss's suggestion which would involve stabilizing this form of "unsafe unreachable" in a different manner.

Isn’t that std::intrinsics::unreachable?

[alexcrichton]

@SimonSapin yeah, I was just thinking that we'd want to pursue stabilizing that intrinsic (in a different location) instead of stabilizing a one-off method on Option.

[hanna-kruppe]

I am unconvinced that I'd even want to do this optimization at all. It's such a tiny gain (avoids a single, trivially predictable branch), and the consequences for getting it wrong (i.e., the value being None) are pretty dire, up to and including interpreting arbitrary bits as as pointer. That's a pretty terribly ratio of potential danger to potential benefit.

I am even less convinced that this optimization needs to be codified in a method in std, especially when it's trivial to express otherwise on nightly. I don't think there is any pressing need to get the possibility of this optimization into stable: There are already many unstable optimizations (e.g., various collection APIs, other intrinsics) that are far more widely applicable, and unreachable will be stabilized in some form or another at some point in the future. If anyone wants this optimization on stable, working to stabilize std::intrinsics::unreachable would probably be more effective as @alexcrichton already said.

I'd appreciate hard data (i.e., well-done benchmarks) showing a measurable performance gain in any non-pathological code --- ideally, a real library or application. But even with that I'd be inclined to say "well that's nice but you can do the same thing yourself, so why bake it into std for all eternity?"

Overall, 👎

[reem]

Also of note: you can now have an unreachable optimization hint in stable code through the unreachable crates.io crate, which provides the same interface as std::intrinsincs::unreachable but doesn't need any unstable code.

[SimonSapin]

the unreachable crates.io crate

Uh, that looks crazy magic to me. Does the complier really eliminate branches that cause transmuting to Void? Reliably?

[reem]

@SimonSapin it works because rustc emits an unreachable hint after all calls to diverging functions.

[bluss]

@SimonSapin rustc's part of the magic is this, it simply emits unreachable when matching an empty enum:

fn unreachable(v: Void) -> ! {
    match v { /* empty */ }
}

[SimonSapin]

I see, thanks for the explanation!

[alexcrichton]

Thanks again for the RFC @dschatzberg! The consensus of the library subteam is to not merge this RFC at this time due to the worries about composability and how stabilizing an unreachable-like function in the standard library (or using @reem's crate) may be the best way to go here.

[dschatzberg]

Thanks for the response, @alexcrichton. Could you clarify what the worries about
composability are?

[alexcrichton]

Ah it's what I meant in a previous comment about how an unreachable function of some form would be more composable instead of only having this method on Option itself.