Suggest replacing .unwrap_or_else(|| panic!("...")) with .expect("...") on Option<T: Debug>

[torokati44]

What it does

Makes this roundabout way of writing .expect actually an expect call where it's feasible.

Advantage

The code is shorter and more straightforward in what it does, and IMHO more idiomatic.

Drawbacks

The parameter to expect is evaluated even when it doesn't end up being used.
Cf. unwrap_or vs. unwrap_or_else.
Not a big deal for literals, but could be significant in rare cases.

Example

This is a straight-up real-world example. I can trim it down upon request.

                full_output.platform_output.cursor_icon = player
                    .ui()
                    .downcast_ref::<DesktopUiBackend>()
                    .unwrap_or_else(|| panic!("UI Backend should be DesktopUiBackend")) // <--
                    .cursor();

(https://github.com/ruffle-rs/ruffle/blob/2621dd78eefab17e98dc03fafa25ed421784a712/desktop/src/gui/controller.rs#L213)

Could be written as:

                full_output.platform_output.cursor_icon = player
                    .ui()
                    .downcast_ref::<DesktopUiBackend>()
                    .expect!("UI Backend should be DesktopUiBackend") // <--
                    .cursor();

[torokati44]

I think this may be related: #19

[Centri3]

This could also lint unreachable! and friends as well, though I tend to write that instead to convey it's 100% unreachable. Could be a configuration option as I do think in any particularly serious projects expect should convey the same meaning as unreachable!.