Tracking issue for promoting `!` to a type (RFC 1216)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1216, which promotes ! to a type.

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Pending issues to resolve

• Regressions from fallback to () without fallback, never type introduces regressions #67225
• How to handle fallback of diverging expressions Tracking issue for fallback of diverging expressions to the never_type (!) #65992

Interesting events and links

• Initial PR Implement the ! type #35162
• Stabilization PR Stabilize ! in Rust 1.41.0 #65355
• Reverting stabilization Revert stabilization of never type #67224 due to regressions Regression in Error conversion from Infallible #66757

Latest Status

#35121 (comment):

The plan, as FCPed here, is to:

1. Change fallback to ! in Rust 2024 (details of this elided as this work is done).
   • Tracking Issue for Rust 2024: Make ! fall back to ! #123748
2. Stabilize Rust 2024.
3. At a later date when 2024 edition adoption is widespread:
   • Make the breaking change to fall back to ! always everywhere.
   • Change Infallible = !.
   • Stabilize ! (!).

Rust 2024 is expected to be released in Q1 2025. We're not sure how long step 3 will take after that.

See the draft edition guide chapter for further background here:

https://doc.rust-lang.org/nightly/edition-guide/rust-2024/never-type-fallback.html

Switching the FCWs to lint in dependencies:

• Report never type lints in dependencies #141937

[canndrew]

Huzzah!

There's a WIP implementation of this here: https://github.com/canndrew/rust/tree/bang_type_coerced

It's current status is: it builds with old-trans and is usable but has a couple of failing tests. Some tests fail due to a bug that causes code like if (return) {} to crash during trans. The other tests are to do with link-time-optimization and have always been buggy for me, so I don't know if they have anything to do with my changes.

My current roadmap is:

• Get it working with MIR. This hopefully won't be too hard as this is how I started implementing it, but I've been having a problem where MIR builds segfault during compilation.
• Purge the obsolete divergence stuff from the compiler (FnOutput, FnDiverging and related).
• Hide the new type behind a feature gate. This would mean, when the feature is disabled:
  • ! can only be parsed as a type in the return position.
  • Diverging type variables default to ().
• Figure out how we can raise compatibility warnings when a defaulted () gets used to resolve a trait. One way to do this could be to add a new type to the AST called DefaultedUnit. This type behaves like () and will turn into () under some circumstances but raises a warning when it resolves a trait (as ()). The problem with this approach is I think it will be hard to catch and fix all the bugs with the implementation - we'd end up breaking people's code in order to save their code from being broken.

Is there anything that needs to be added to this list? Is it just going to be me working on this? And should this branch be moved onto the main repository?

[canndrew]

Figure out how we can raise compatibility warnings when a defaulted () gets used to resolve a trait. One way to do this could be to add a new type to the AST called DefaultedUnit. This type behaves like () and will turn into () under some circumstances but raises a warning when it resolves a trait (as ()). The problem with this approach is I think it will be hard to catch and fix all the bugs with the implementation - we'd end up breaking people's code in order to save their code from being broken.

@eddyb, @arielb1, @anyone_else: Thoughts on this approach? I'm pretty much up to this stage (sans a couple of failing tests that I'm (very slowly) trying to fix).

[tomaka]

What traits should we implement for !? The initial PR #35162 includes Ord and a few others.

Shouldn't ! automatically implement all traits?

This kind of code is fairly common:

trait Baz { ... }

trait Foo {
    type Bar: Baz;

    fn do_something(&self) -> Self::Bar;
}

I'd expect ! to be usable for Foo::Bar in order to indicate that a Bar can never actually exist:

impl Foo for MyStruct {
    type Bar = !;
    fn do_something(&self) -> ! { panic!() }
}

But this is only possible if ! implements all traits.

[suhr]

@tomaka There's RFC about it: rust-lang/rfcs#1637

The problem is that if ! implements Trait it also should implement !Trait...

[tomaka]

The problem is that if ! implements Trait it also should implement !Trait...

Then special-case ! so that it ignores any trait requirement?