Stabilize never_type *again*

[cramertj]

#49593 has now been fixed. This was the reason for the previous revert of stabilization (#50121). Previous stabilization report is [here]. Let's try this again!

@rfcbot fcp merge
cc #35121

(pnkfelix notes :the previous issue discussing stabilization of ! was #48950; its possible the [here] above was supposed to link to that...)

[cramertj]

@rfcbot fcp merge

c'mon, rfcbot!

[rfcbot]

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

• @Centril
• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @cramertj
• @dtolnay
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @sfackler
• @withoutboats

Concerns:

• 49039-needs-decision resolved by Stabilize never_type *again* #57012 (comment)
• fallback (Stabilize never_type *again* #57012 (comment))
• from-impl resolved by Stabilize never_type *again* #57012 (comment)
• fundamental-and-fn-traits resolved by Stabilize never_type *again* #57012 (comment)
• impls resolved by Stabilize never_type *again* #57012 (comment)
• indirect-coherence-breakage (Stabilize never_type *again* #57012 (comment))
• more-elaborate-report resolved by Stabilize never_type *again* #57012 (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]

@rfcbot concern impls

The remaining unchecked checkbox in the description of #35121 is:

What traits should we implement for !? The initial PR #35162 includes Ord and a few others. This is probably more of a T-libs issue, so I'm adding that tag to the issue.

Stabilizing ! and then (in a) later (release cycle) adding a new impl of existing traits is not a breaking change, is it? If not, this doesn’t need to be a blocker and let’s mark this as resolved immediately.

If it is, let’s discuss it in this issue. Currently in https://doc.rust-lang.org/nightly/std/primitive.never.html we have:

impl Hash for !
impl Copy for !
impl Debug for !
impl Clone for !
impl PartialOrd<!> for !
impl Ord for !
impl Eq for !
impl PartialEq<!> for !
impl Display for !
impl Error for !
impl Termination for !

@rust-lang/libs, anything to add?

[withoutboats]

@SimonSapin it's not a breaking change AFAIK, so we can add them over time.

I'm not sure if we should implement traits for !. Under some coherence related proposals, its possible to write impls guaranteeing that a type will never implement a trait - negative impls, in other words. I don't know the pros and cons of providing positive vs negative impls for ! (which could go either way) if that feature were added to the language.

[SimonSapin]

@rfcbot concern fallback

In addition to reverting the stabilization, #50121 also reverted “to the previous fallback semantics (i.e. it is once again dependent on whether the crate has opted into #[feature(never_type)]”.

As far as I understand, this is about type inference of a diverging expression like panic!(…), where there is no constraint from surrounding code.

When it previously landed in Nightly, we found out #35121 (comment) that the fallback change could cause some previously-valid code to not compile anymore: #48950 (comment), and some (other) previously-valid unsafe code to now have Undefined Behavior #48950 (comment) (returning Result<!, _>::Ok in reachable/reached code).

[SimonSapin]

Is this a duplicate of #48950?

[cramertj]

@SimonSapin That issue was created during the first round of stabilization to capture the conversation around that issue. This is the new issue for the new round of stabilization.