-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
"stabilize never type" T-types FCP #161925
Copy link
Copy link
Open
Labels
F-never_type`#![feature(never_type)]``#![feature(never_type)]`T-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.This issue / PR is in PFCP or FCP with a disposition to merge it.needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.This issue may need triage. Remove it if it has been sufficiently triaged.proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
Description
Metadata
Metadata
Assignees
Labels
F-never_type`#![feature(never_type)]``#![feature(never_type)]`T-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.This issue / PR is in PFCP or FCP with a disposition to merge it.needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.This issue may need triage. Remove it if it has been sufficiently triaged.proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
We forgot to T-types FCP #155499. See that PR for more detail.
As discussed on zulip:
This PR has three changes which make it worthy of a Types FCP
Allow users to name
!directly. It was already possible to use!outside of function return types by using the following pattern:However, I remember us generally discouraging users from writing such impls. I don't think there are any significant complications from users being able to implement traits for
!more widely. So this seems fine to me.This PR also changes the "never type fallback" to always fall-back to
!instead of()in old editions: 6656056. See the crater results for that change in #155499 (comment). This affects any inference variable resulting from a never-to-any coercion which we apply whenever we're coercing an value expression with type!, see #155499 (comment).Finally, we're setting
Infallibleto be a type alias for!instead of an enum without any variants. This was done in #155924. While this change isT-libs, we did 3 Types FCPs to minimize its impact.@WaffleLapkin mentioned 4 kinds of breakage in #155924 (comment):
T-typesissue :>impl<T> From<!> for T#64715 From<!> impls. After making Infallible = !, this reservation impl can conflict with existing implementations for Infallible - This breaks 14 crates total (including reverse-dependencies of broken crates)From<!> for T*reservation* impl #160705