-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: