Add std::panic::panic_any.

[m-ou-se]

The discussion of #67984 lead to the conclusion that there should be a macro or function separate from std::panic!() for throwing arbitrary payloads, to make it possible to deprecate or disallow (in edition 2021) std::panic!(arbitrary_payload).

Alternative names:

• panic_with!(..)
• start_unwind(..) (panicking doesn't always unwind)
• throw!(..)
• panic_throwing!(..)
• panic_with_value(..)
• panic_value(..)
• panic_with(..)
• panic_box(..)
• panic(..)

The equivalent (private, unstable) function in libstd is called std::panicking::begin_panic.

I suggest panic_any, because it allows for any (Any + Send) type.

Tracking issue: #78500

[rust-highfive]

r? @shepmaster

(rust_highfive has picked a reviewer for you, use r? to override)

[daboross]

To bikeshed the name a bit more, what about panic_with_value, referring to the fact that one can provide any value? I don't think we necessarily need a short name here, given how infrequently used it is (though if there were a short name which fits well, that would be better).

I'd personally prefer panic_with_value over panic_box (or panic_with_box) just because the fact that it can transmit anything seems slightly more intuitive than the fact that that transmission is done through a box? Though if it did take a Box<dyn Any + Send + 'static>, rather than taking T and boxing it as an implementation detail, I think panic_box (or I think I'd still prefer panic_with_box) could fit well.

[shepmaster]

My own 2¢ on the name — I'd want panic_value!

[nikomatsakis]

Nominating to make @rust-lang/lang members aware of this.

[nikomatsakis]

Regarding naming, I agree that something based on "value" is preferable to "box". The fact that boxing occurs doesn't feel like the important thing for users to keep in mind. I'm happy with panic_with_value, panic_value, or even panic_with, although I raised a concern on that last one.

[nikomatsakis]

That said, we discussed this in the @rust-lang/lang meeting today and we felt like this sort of bikeshedding is really a @rust-lang/libs affair, so i'm going to retag this as T-libs.

[joshtriplett]

Could we separate the idea of having a separate macro for "panic with this specific value" from the "there's one argument and it's a string literal" case? I'd love to see the 2021-edition panic! on a string literal always treat it as a format string if it contains any format arguments, and emit a compile-time error if those arguments aren't satisfied. That seems separable from "what do we do if there's one argument and it isn't a string literal".

[SimonSapin]

to deprecate or disallow (in edition 2021) std::panic!(arbitrary_payload).

That doesn’t seem possible. As far as I know we cannot make macros behave differently based on the edition of the call site. (Editions are per-crate, so std itself is in one edition.)

[Mark-Simulacrum]

It would require compiler magic, I suppose, but only in a more general way, by adding something like #[deprecated(since = "edition2021")]. That would be straightforward to add to the compiler I think and is also desirable for the MIN/MAX constants and such.

[bors]

☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

So, it feels like we need to discuss this PR in the context of the full plan. As I understood it, the plan was this:

• In 2021 Edition:
  • std::panic! requires a string literal and literal is treated as a format string
  • std::panic_with_value accepts only a value
• In 2018 Edition:
  • std::panic! gets a migration warning if it has no arguments and there is a suggestion to rewrite to panic_with_value -- this is a bit debatable, and we should discuss the particulars, but it seems strictly necessary from my POV to avoid changing runtime semantics

I forget what we would do about core::panic...

The hope was indeed that in 2021 Edition crates, the panic! macro would always begin with a string literal, and that literal would be treated as a format string. It was mentioned that this could be achieved by having the prelude depend on the edition, such that we had panic! route to a distinct macro in the 2021 Edition. It certainly seems possible for us to do it in some way, but we'd have to think about the best impl strategy.

[Mark-Simulacrum]

core::panic! can't accept arbitrary expressions in the single-argument case, only &str, so I would suspect something like this:

• In 2021 Edition:
  • core::panic! requires a string literal and literal is treated as a format string
    • We may need to explicitly optimize the "identity" case to not bring in format infrastructure, though, for code size reasons.
• In 2018 Edition:
  • core::panic!("{:?}") and other single-argument but format strings emit future-compat warnings
    * if you want this, you should write core::panic!("{}", "{:?}") or core::panic!("{{:?}}")

[m-ou-se]

We may need to explicitly optimize the "identity" case to not bring in format infrastructure, though, for code size reasons.

That's already taken care of by #74056

[sfackler]

Why does panic_with_value! need to be a macro at all rather than a normal function?

[nikomatsakis]

@sfackler it doesn't, I think that was me just typing wrong

[Dylan-DPC-zz]

@m-ou-se if you can resolve the conflicts, we can push this forward

[KodrAus]

We discussed this in the recent Libs meeting and felt happy with the name panic_any. We felt happy to merge this and move discussion over to the RFC itself. With that in mind...

@bors r+ rollup

[bors]

📌 Commit b48fee0 has been approved by KodrAus