Summary issue - stabilization of !

[canndrew]

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.

• Type inference will now default unconstrained type variables to ! instead of (). The resolve_trait_on_defaulted_unit lint has been retired. An example of where this comes up is if you have something like:

  // We didn't specify the type of `x`. Under some circumstances, type inference
  // will pick a type for us rather than erroring
  let x = Deserialize::deserialize(data);

  Under the old rules this would deserialize a (), whereas under the new rules it will deserialize a !.

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

[nikomatsakis]

Note decision was made to stabilize here.

[scottmcm]

I had a thought that I think needs to be resolved in the same release as this stabilization: Is there an existing stable uninhabited type in core/std that we want to make an alias for !? (AFAIK we could only do this for one of them, since coherence.)

The one that comes to mind for me is std::string::ParseError...

[nikomatsakis]

@scottmcm I don't think there's a ton of motivation to do that -- I believe that, when all is said and done, empty enums and ! will behave quite similarly in most ways, apart from coercions. Notably in matches.

[nikomatsakis]

Still, interesting thought. Maybe nicer just for simplicity?

cc @rust-lang/libs -- see @scottmcm's suggestion above about making uninhabited types like string::ParseError an alias for !

[sfackler]

I had always assumed that all of the void errors would turn into type aliases for ! but I hadn't thought of the coherence issue. How many do we actually have? It seems like it may not be worth changing just one of many.

[alexcrichton]

Yeah I was also personally under the impression that we'd change the types to be aliases and run crater to see if it actually had any fallout (as at the time I don't think we expected much)

[nikomatsakis]

Well, I just r+'d the ! stabilization PR, so we have until the next release. =)

[scottmcm]

Well I only found 3 (ParseError, unstable Infallible, and new-for-1.26 ParsePathError) so PR up: #49039

[mitsuhiko]

Not sure if this is a regression you care about but the findshlibs crate now fails compiling some tests on beta and nightly as a result of this stabilization: https://travis-ci.org/gimli-rs/findshlibs/jobs/364806360

The code in question:

        match panic::catch_unwind(|| { TargetSharedLibrary::each(|_| panic!("uh oh")); }) {
            Ok(()) => panic!("Expected a panic, but didn't get one"),
            Err(any) => {
                assert!(any.is::<&'static str>(), "panic value should be a &'static str");
                assert_eq!(*any.downcast_ref::<&'static str>().unwrap(), "uh oh");
            }
        }

Error message:

error[E0277]: the trait bound `IterationControl: std::convert::From<!>` is not satisfied
   --> src/lib.rs:326:40
    |
326 |         match panic::catch_unwind(|| { TargetSharedLibrary::each(|_| panic!("uh oh")); }) {
    |                                        ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::convert::From<!>` is not implemented for `IterationControl`
    |
    = help: the following implementations were found:
              <IterationControl as std::convert::From<()>>
    = note: required because of the requirements on the impl of `std::convert::Into<IterationControl>` for `!`
note: required by `SharedLibrary::each`
   --> src/lib.rs:296:5
    |
296 | /     fn each<F, C>(f: F)
297 | |     where
298 | |         F: FnMut(&Self) -> C,
299 | |         C: Into<IterationControl>;
    | |__________________________________^
error: aborting due to previous error

[nikomatsakis]

@canndrew looking at @mitsuhiko's issue, and just thinking generally -- I was wondering -- what is the classic example of why fallback to () would "have" to be changed? That is, if we continued to fallback to (), but still added !, it would certainly avoid that sort of problem -- and falling back to ! is not optimal, given that there are cases where the fallback occurs to a type variable that winds up influencing "live" code (the intention of course is otherwise, but it's hard to prevent leaks, as we've found).

[nikomatsakis]

Nominating for brief lang-team discussion around this final point

[SimonSapin]

For what it’s worth the fallback change caused some previously-valid unsafe code to go Very Wrong: rust-windowing/winit#428, servo/servo#20474 (comment).

In short: generic FFI bindings in the objc crate end up returning Ok(x: R) where R is an unconstrained type parameter whose inference changed from () to !. So now (to simplify) the Result<!, String>::Ok value is incorrectly assumed to be Err, and on drop we deallocate a String whose pointer is made of padding bytes. jemalloc is not amused. The fix is changing statements like send!(…); to force the return type: let () = send!(…);

[nikomatsakis]

@SimonSapin ah yes thanks for raising that

[nikomatsakis]

Cross-posted my question to the main tracking issue, and added a few details. That seems like a better place to have this conversation.

[SimonSapin]

Should this be closed? The last comment pre-dates #50121 and now #57012.

[pnkfelix]

closing since we have started a new round of stabilization in #57012 and so we should try to capture all concerns and other threads of conversation there.