Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document never type fallback in !'s docs #124419

Merged
merged 5 commits into from
May 2, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
47 changes: 47 additions & 0 deletions library/core/src/primitive_docs.rs
Expand Up @@ -268,6 +268,53 @@ mod prim_bool {}
/// [`Debug`]: fmt::Debug
/// [`default()`]: Default::default
///
/// # Never type fallback
///
/// When the compiler sees a value of type `!` in a [coercion site], it implicitly inserts a
/// coercion to allow the type checker to infer any type:
///
/// ```rust,ignore (illustrative-and-has-placeholders)
/// // this
/// let x: u8 = panic!();
///
/// // is (essentially) turned by the compiler into
/// let x: u8 = absurd(panic!());
///
/// // where absurd is a function with the following signature
/// // (it's sound, because `!` always marks unreachable code):
/// fn absurd<T>(_: !) -> T { ... }
// FIXME: use `core::convert::absurd` here instead, once it's merged
/// ```
///
/// This can lead to compilation errors if the type cannot be inferred:
///
/// ```compile_fail
/// // this
/// { panic!() };
///
/// // gets turned into this
/// { absurd(panic!()) }; // error: can't infer the type of `absurd`
/// ```
///
/// To prevent such errors, the compiler remembers where it inserted `absurd` calls, and
/// if it can't infer the type, it uses the fallback type instead:
/// ```rust, ignore
/// type Fallback = /* An arbitrarily selected type! */;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Arbitrarily selected" here sounds like "the compiler picks from some set", not "we made a choice and taught it to the compiler". I'm not sure what would be better, though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's nothing stopping us from having arbitrarily complicated fallback logic, aside from a reluctance to implement anything more complex, which is why I suggested it that way.

We do pick from a set.

The set has one member. :^)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hoping to grow the set to two :p

I'm also not a fan of "arbitrary" here because we did purposefully choose the fallback type...

But I'm not sure how to phrase this properly :/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whenever I use arbitrary I strongly mean the "the reason for why is because I said so", because often there were multiple reasonable choices we could have made, but we could only make one (one set, with any number of members).

/// { absurd::<Fallback>(panic!()) }
/// ```
///
/// This is what is known as "never type fallback".
///
/// Historically, the fallback type was [`()`], causing confusing behavior where `!` spontaneously
/// coerced to `()`, even when it would not infer `()` without the fallback. There are plans to
/// change it in the [2024 edition] (and possibly in all editions on a later date); see
/// [Tracking Issue for making `!` fall back to `!`][fallback-ti].
///
/// [coercion site]: <https://doc.rust-lang.org/reference/type-coercions.html#coercion-sites>
/// [`()`]: prim@unit
/// [fallback-ti]: <https://github.com/rust-lang/rust/issues/123748>
/// [2024 edition]: <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/index.html>
///
#[unstable(feature = "never_type", issue = "35121")]
mod prim_never {}

Expand Down