Tracking Issue for Rust 2024: Make ! fall back to ! · Issue #123748 · rust-lang/rust (original) (raw)

This is a tracking issue for the change to make fallback fall back from ! to ! (rather than to ()) in Rust 2024. This is part of a plan that leads to eventually stabilizing the never (!) type.

What this change means

This change means that ! does not spontaneously decay to (). For example, consider this code:

fn print_return_type(_: fn() -> R) { println!("{}", std::any::type_name::()); }

print_return_type(|| todo!()); // before this change: prints () // after this change: prints !

todo!() "returns" !, but before this change this ! decayed to () when being returned from the closure. In general, this can happen at any coercion site, if the type is not set by something else.

If your code is broken with errors like `!: Trait` is not satisfied, then you need to make sure the type is specified explicitly. For example:

fn create_zst<T: From<()>>() -> T { ().into() }

if condition { create_zst() } else { return };

Before this change ! from return decays to (), meaning that create_zst will also return (), and since () implements From<()> this was fine. With this change however, ! from return keeps being ! and inference makes create_zst also return !, however ! does not implement From<()> causing a compilation error.

The easiest fix is to specify the type explicitly:

if condition { create_zst::<()>() } else { return };

However, this can also be a sign that you don't care what the type is, and maybe the better solution is to refactor the code.

Also note that this "create something or return" pattern can also be caused by ? with code like this:

Because deserialize's output type is not bound to be anything, it gets inferred from ?'s desugaring that includes a return. (there is a separate initiative to stop ? from affecting inference like this: #122412)

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Unresolved Questions