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