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

Tracking issue for fallback of diverging expressions to the never_type (!) #65992

Closed
2 tasks
Centril opened this issue Oct 31, 2019 · 2 comments
Closed
2 tasks
Labels
A-inference Area: Type inference B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-never_type `#![feature(never_type)]` requires-nightly This issue requires a nightly compiler in some way. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Oct 31, 2019

This issue is tracking the proposed change in fallback for "abrupt" expressions (part of the ! type RFC, tracking issue #35121).

Substeps

@Centril Centril added T-lang Relevant to the language team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. requires-nightly This issue requires a nightly compiler in some way. labels Oct 31, 2019
Centril added a commit to Centril/rust that referenced this issue Nov 21, 2019
…li-obk

Stabilize `!` in Rust 1.41.0

This PR stabilizes the `never_type` (written `!`). The type represents computations that we know diverge in the type system and therefore has no values / inhabitants / elements / members.

The current nightly version is 1.40.0 which will become stable on 2019-12-19.

Tracking issue: rust-lang#35121.
Closes rust-lang#57012.
Closes rust-lang#58184.
Original stabilization report: rust-lang#57012 (comment)

Additional notes:

- In rust-lang#62661 we reserved `impl<T> From<!> for T` so this concern should be resolved.
- The type inference fallback change is moved to `#![feature(never_type_fallback)]` (rust-lang#65992).
- You can find all of the tests referencing `never_type` in this PR which also reorganizes these tests whereas they were more scattered before.

r? @nikomatsakis
@bill-myers
Copy link
Contributor

bill-myers commented Nov 28, 2019

It seems to me this change is wrong as-is, since it causes a bare call to mem::zeroed() with unused result to panic, which is obviously absurd.

Based on https://hackmd.io/3VA7vpBFQZCZFjhVSh4O-A it seems to me that the problem is that the type of panic! and unimplemented! is an unbound inference variable, where in fact it should just be the "!" type.

With such a change, those expressions will have the "!" type even when fallback is to (), and that's the only argument in favor listed.

If fallback to "!" is still desired, then it DEFINITELY must not happen in places where it would cause code to panic that would not panic if the fallback was to "()" like simply calling mem::zeroed(): the thing that comes to mind is to add a "NotNever" or "Inhabited" trait bound to everything that uses unsafe code to generate arbitrary types like mem::zeroed, mem::uninitialized and mem::transmute, but not quite sure about this (especially because it seems it would be an incompatible change).

@Mark-Simulacrum
Copy link
Member

Closing in favor of #35121 -- I don't think a separate tracking issue for components of never is particularly necessary. It's also somewhat likely that we're not going to end up changing fallback for never type-related things, regardless, due to the breaking changes and other complexity involved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-inference Area: Type inference B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-never_type `#![feature(never_type)]` requires-nightly This issue requires a nightly compiler in some way. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants