-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Stabilize (only) the never type #58184
Comments
@rfcbot fcp merge There is currently a lack of consensus regarding the change to fallback and how to handle edge case breakages. I don't believe there is any reason this change has to be tied together with making |
Team member @withoutboats has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
It was pointed out to me that |
@rfcbot concern motivation-to-change-fallback I'm concerned that if we stabilize |
@rfcbot concern eddybs-concern-on-the-other-issue See #57012 (comment). |
What is the status on this? |
As far as I know the status has not significantly changed since my summary in #57012 (comment). |
The concern labelled "eddybs-concern-on-the-other-issue" has been resolved by #62661. |
Indeed it has. @rfcbot resolve eddybs-concern-on-the-other-issue |
I'll resolve my concern on this (motivation-to-change-fallback) pending a lang team discussion as proposed in #65355 (comment). |
Sorry for the labels nonsense-- something is going wacky with GH in my browser. |
This is an alternative to #57012 that does not propose changing the type inference fallback (yet). This unblocks
TryFrom
andTryInto
#33417.#49593 has now been fixed. This was the reason for the previous revert of stabilization (#50121).
What is being stabilized
!
is now a full-fledged type and can now be used in any type position (eg. RFC 1216). The!
type can coerce into any other type, see https://github.com/rust-lang/rust/tree/master/src/test/run-fail/adjust_never.rs for an example.never_type
feature gate is stable, although some of the behaviours it used to gate now live behind the newexhaustive_patterns
feature gate (see below).What is not being stabilized
Exhaustive pattern-matching for uninhabited types. eg.
This code will still complain that
Ok(_)
is a refutable pattern. This can be fixed by using theexhaustive_patterns
feature gate. See RFC 1872 for progress on this issue. See https://github.com/rust-lang/rust/tree/master/src/test/ui/feature-gate-exhaustive-patterns.rs for the testcase which confirms that this behaviour is still gated.The type inference changes proposed in Summary issue - stabilization of
!
#48950 are not part of this proposal, since they can break some previously-valid programs and the mitigations discussed in Stabilize never_type *again* #57012 are not ready yet.This change is moved to a new dedicated feature gate,
inference_fallback_to_never
, instead ofnever_type
.The text was updated successfully, but these errors were encountered: