Stabilize (only) the never type

[SimonSapin]

This is an alternative to #57012 that does not propose changing the type inference fallback (yet). This unblocks TryFrom and TryInto #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.
• The 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).

What is not being stabilized

• 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 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 of never_type.

[withoutboats]

@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.

[rfcbot]

Team member @withoutboats has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Centril
• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @withoutboats

Concerns:

• eddybs-concern-on-the-other-issue resolved by Stabilize (only) the never type #58184 (comment)
• motivation-to-change-fallback (Stabilize (only) the never type #58184 (comment))

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.

[SimonSapin]

It was pointed out to me that #![feature(never_type)] changes inference in current Nightly. I’ve edited the proposal to mention moving that to a new feature gate.

[cramertj]

@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.

[Centril]

@rfcbot concern eddybs-concern-on-the-other-issue

See #57012 (comment).

[mati865]

What is the status on this?
There was no voting activity since 18 April.

[SimonSapin]

As far as I know the status has not significantly changed since my summary in #57012 (comment).

[withoutboats]

The concern labelled "eddybs-concern-on-the-other-issue" has been resolved by #62661.

[Centril]

Indeed it has.

@rfcbot resolve eddybs-concern-on-the-other-issue

[cramertj]

I'll resolve my concern on this (motivation-to-change-fallback) pending a lang team discussion as proposed in #65355 (comment).