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

[Ericson2314]

for<E> E: From<!>

Is nice for error handling, but I recall there are orphan/overlapping issues adding it later. I think this is because that impl is technically an overlapping impl with for<A> A: From<A>, so downstream impls that would overlap with it aren't orpans. But if we somehow hack that into core, then the downstream impls can't exist.

[SimonSapin]

@Ericson2314 I agree that impl<T> From<!> for T would be nice to have. Indeed, if we ever add it, that needs to happen before or in the same release cycle as stabilization of !. And as you said, we can’t "just" add it because it overlaps with impl<T> From<T> for T.

Adding "some hack" to bend the language rules and somehow allow both these impls (picking an arbitrary one to "win" is ok, since they behave the same at the intersection) has been discussed before in the abstract, but there has never been a concrete proposal. Concretely, this would need:

• A plan for how this would work in terms of compiler implementation
• Some buy-in from the language team that bending the language rules in libcore is not a non-starter
• Someone who volunteers to implement it

Without all of these things soon, I suspect that consensus would be to give up on impl<T> From<!> for T and stabilize ! without it.

[Centril]

Noting so I/we remember from this week's T-lang meeting:

@rfcbot concern fundamental-and-fn-traits

We had some discussion around Fn* traits (which are #[fundamental]) and !. (Are there other fundamental traits?) @cramertj and @withoutboats had some ideas that would be nice to hear more in-depth about.

@rfcbot concern more-elaborate-report

It would be nice to have all the behavior changes more clearly specified in one place before we stabilize so it's clear what is being stabilized.

@rfcbot concern from-impl

Noting this as a concern temporarily until conversation has resolved itself.

[SimonSapin]

When it previously landed in Nightly, we found out that the fallback change could […]

I meant to add: in #35121 (comment) we discussed only making the fallback change in a new edition. We missed the 2018 train, so this would be for 2021 (or whenever we’ll make the next one).

Also, in the #48950 (comment) case, fallback occurred in the expansion of a macro_rules macro. But macros are not edition-hygienic, are they?

[glaebhoerl]

Adding "some hack" to bend the language rules and somehow allow both these impls (picking an arbitrary one to "win" is ok, since they behave the same at the intersection) has been discussed before in the abstract, but there has never been a concrete proposal. Concretely, this would need:

I don't know whether this would actually be easier to implement than the "some hack" itself which would allow the From impls to coexist, but another option which could unblock this question for now, without forever giving up on the right to add the From<!> impl, would be to add a temporary hack which just forbids downstream crates from writing any impls which would conflict with it (as-if the impl did exist), without actually adding the impl itself in core yet.

To try to avoid confusion I'll call the (hypothetical) hack which allows From<!> and From<T> to coexist the "overlap hack", and the hack which merely forbids downstream from conflicting with it the "future-proofing hack".

Even if it's not easier to implement, the future-proofing hack requires fewer commitments -- we don't have to commit to the From<!> impl existing and being stable (IINM, impls are still insta-stable, exacerbating the whole issue), we don't have to commit to the overlap hack existing and continuing to work in the future, we can revert the future-proofing hack at any point if we decide it's not worth it.

[SimonSapin]

But the future-proofing hack blocks a useful use case.

For the same reason that impl<T> From<!> for T is desirable, if it’s not implemented then impl From<!> for Foo might be desirable as the next best thing.

[glaebhoerl]

Yes, which is why it's good that we can choose to revert it at any time.

[cramertj]

An alternative in the future would be to add the impl but ignore coherence completely for any From<!> impl and just allow overlap, since all possible implementations are equivalent (we could potentially do the same for any traits where all functions have uninhabited arguments, and there are no non-function associated items).

[SimonSapin]

I like the idea of tweaking coherence not with a special case for a particular pair of impls but with a rule about allowing overlap when the intersection only has unreachable functions. There is somewhat similar precedent in https://rust-lang.github.io/rfcs/1268-allow-overlapping-impls-on-marker-traits.html, although like in that case we might want to make it opt-in.

[cramertj]

@Centril

concern fundamental-and-fn-traits
We had some discussion around Fn* traits (which are #[fundamental]) and !. (Are there other fundamental traits?) @cramertj and @withoutboats had some ideas that would be nice to hear more in-depth about.

TL;DR: We shouldn't implement the Fn traits for !, because they have an associated type and we'd have to choose what it is. One option would be to choose !, but there's no real logical / fundamental reason for this. Instead, providing this implementation would actually prevent users from implementing custom traits for ! where they also wanted to add a blanket impl over all T: Fn.... This seems like a potentially useful thing to do, whereas using ! as a Fn...<...> -> ! or Fn...<...> -> () seems not particularly useful.

[Ericson2314]

@SimonSapin I really like that idea! We could use the same logic that deduces there is only one possible impl to also allow elliding the trait items:

impl<T> From<!> for T;

[SimonSapin]

#57012 (comment)

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

@rfcbot resolve impls

---

@cramertj How do you feel about making this issue explicitly not propose any change to type inference fallback from () to !, and leave that change to future discussions? This would resolve my "fallback" concern: #57012 (comment)

[SimonSapin]

#57012 (comment)

I like the idea of tweaking coherence not with a special case for a particular pair of impls but with a rule about allowing overlap when the intersection only has unreachable functions.

I believe this would be compatible to add later, after the never type is stabilized. And so this doesn’t need to block this FCP. @Centril, does this resolve your from-impl concern?

[Ericson2314]

@SimonSapin ah so to be clear, if we have Foo: From<!>, and then we add the blanket impl, the Foo impl becomes a harmless overlap (even if it is fully subsumed) by the same analysis.

[SimonSapin]

Since discussion seems to have stalled, I’ll try to summarize the remaining concerns.

• This FCP proposes two things: stabilizing the never type, and changing type inference fallback. In some rare cases, the latter can change the meaning of previously-valid stable unsafe code and make it unsound: Stabilize never_type *again* #57012 (comment). (Disclosure, I filed this one.) Possible resolutions include:

  • Tweak the proposed inference rules so that they don’t change the meaning of existing code in cases where that would be unsound. It’s not clear if this is possible.
  • Design and implement mitigations that will help project maintainers find out if their code or their dependencies’ code is affected. (Crater is not sufficient since it only tests open-source code that it can find, only on Linux, and only with a fixed set of system packages installed, and only runs unit tests at most.) It’s not clear yet what these mitigations should do exactly.
  • Declare this breaking change to be “minor”, hope that it causes more benign crashes than exploitable vulnerabilities, and let project maintainers deal with it however they can. I personally think this is not acceptable.
  • Stabilize the never type separately (Stabilize (only) the never type #58184) from the inference change, since it is not actually affected by this concern, and keep discussing tweaks or mitigations in another thread.

• It would be nice to have impl<T> From<!> for T to reflect at the trait level that a “value” of the never type can be trivially converted to any type (since that code is unreachable). However trait coherence does not let us write that impl since it overlaps with the stable identity conversion impl<T> From<T> for T, for T = !. And adding it after the never type has already been stable would be a breaking change: Stabilize never_type *again* #57012 (comment). Possible resolutions include:

  • Lattice impl specialization. (However even “basic” specialization has big remaining design questions at this point.)
  • Extend RFC 1268 “Allow overlapping implementations for marker traits” to also include traits with only methods that take at least one parameter whose type is uninhabited.
  • Hack in a narrower special case of one of the above: have a permanently-unstable language rule just for this one standard library impl
  • Give up on this impl. It would be nice to have, but is it really worth blocking the never type from stabilization for so long?

[nikomatsakis]

Nominating for discussion in lang-team meeting to try and get "unstuck". We discussed a bit today.

I think we generally agreed that, with respect to the second question at least, an appealing option would be to extend coherence so that it was treated "as if" such an impl existed, without actually having the impl. That would require some careful coding, though, from what I can tell.

It would certainly be easier to just allow this impl to "opt out" from coherence rules -- I wonder what it would take to convince ourselves that specialization will allow the impl. (It seems very likely to me that it would, but I've not given deep thought to it.)

Regarding the fallback, there is definitely a "core disagreement" here between (a) missing an opportunity to have the "right" fallback and (b) affecting existing code. I am curious about the "mitigations" option -- @SimonSapin are you thinking of something like a lint?

[Centril]

We did not have any time to discuss the issue this week on the language team meeting; rescheduling for next week instead.

[Centril]

Postponing until a future meeting.

[dnrusakov]

@Centril Are there any news on never type stabilization? What is the current status?

[Centril]

@dnrusakov Still the same as before; see #57012 (comment) and #57012 (comment). I think the main blocker now is the future proofing some sort of perma-unstable reservation hack. I'm not familiar with those parts of the compiler to do that, but maybe @eddyb or @arielb1 can.

[agausmann]

How useful / necessary is the trait impl? Conversion from ! to any type T can be trivially done using the empty match statement. I wouldn't mind writing something like result.map_err(|never| match never {})? until this is resolved.

[agausmann]

I re-read everything and I get it now - avoiding problems from impl<!> for MyType. 👍

[crlf0710]

Now that #62661 is merged, what's next?
@eddyb i believe indirect-coherence-breakage concern can be resolved now?

what can we do on the fallback part?

[Centril]

Canceling FCP here in favor of the one in #65355.

@rfcbot cancel

[rfcbot]

@Centril proposal cancelled.