This is an alternative to https://github.com/rust-lang/rust/issues/57012 that does not propose changing the type inference fallback (yet). This unblocks TryFrom and TryInto https://github.com/rust-lang/rust/issues/33417.
! 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 new exhaustive_patterns feature gate (see below).Exhaustive pattern-matching for uninhabited types. eg.
let x: Result<u32, !> = ...;
let Ok(y) = x;
This code will still complain that Ok(_) is a refutable pattern. This can be fixed by using the exhaustive_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 https://github.com/rust-lang/rust/issues/48950 are not part of this proposal, since they can break some previously-valid programs and the mitigations discussed in https://github.com/rust-lang/rust/issues/57012 are not ready yet.
This change is moved to a new dedicated feature gate, inference_fallback_to_never, instead of never_type.
@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 ! usable from stable, for which we have a strong consensus and a lot of groundwork laid. I think its a reasonable way to move forward for us to separate these two changes, so we can stabilize ! now without blocking it (and by extension, TryFrom) on reaching consensus about the fallback changes.
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 #![feature(never_type)] changes inference in current Nightly. I鈥檝e edited the proposal to mention moving that to a new feature gate.
@rfcbot concern motivation-to-change-fallback
I'm concerned that if we stabilize ! now without the fallback change then there won't be sufficient motivation for us to land the fallback change later, and we'll lose out on a feature that would have made the language better. IMO we should go ahead with the full stabilization-- there are inference changes that we don't currently warn against, but we've traditionally allowed such breakages in other places and I don't believe this change is more significant or detrimental.
@rfcbot concern eddybs-concern-on-the-other-issue
See https://github.com/rust-lang/rust/issues/57012#issuecomment-460740678.
What is the status on this?
There was no voting activity since 18 April.
As far as I know the status has not significantly changed since my summary in https://github.com/rust-lang/rust/issues/57012#issuecomment-467889706.
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 https://github.com/rust-lang/rust/pull/65355#issuecomment-541818923.
Sorry for the labels nonsense-- something is going wacky with GH in my browser.
Most helpful comment
@rfcbot concern motivation-to-change-fallback
I'm concerned that if we stabilize
!now without the fallback change then there won't be sufficient motivation for us to land the fallback change later, and we'll lose out on a feature that would have made the language better. IMO we should go ahead with the full stabilization-- there are inference changes that we don't currently warn against, but we've traditionally allowed such breakages in other places and I don't believe this change is more significant or detrimental.