never type stabilization

[nikomatsakis]

Summary

Long term goal is to stabilize the ! type and in particular to alter fallback for "diverging type variables" to use ! and not ().

Current status

Working towards a lint that catches the problems associated with changing fallback (rust-lang/rust#66173). Have a draft PR rust-lang/rust#74535 that is being developed by @blitzerr.

Info

• Lead: @nikomatsakis
• Lang-team liaison: @nikomatsakis
• Charter -- not yet written
• Zulip stream #t-lang/project-never-type
• Relevant rust tracking issues: Tracking issue for fallback of diverging expressions to the never_type (!) rust#65992, create a lint for tracking "tainted" fallback around abrupt expressions and ! type rust#66173, Tracking issue for promoting ! to a type (RFC 1216) rust#35121

What is this issue?

This issue represents an active project group. It is meant to be used for
the group to post updates to the lang team (and others) in a lightweight
fashion. Please do not use the comments here for discussion, that should be kept
in the Zulip stream (discussion comments here will be marked as off-topic).

[nikomatsakis]

Status update 2020-10-12:

@blitzerr and I spent some time looking at the implemenation. We produced an isolated test case for the false warnings that we are getting when building libcore but as far as I know haven't tracked down their cause yet.

[nikomatsakis]

Status update 2020-10-26:

Still poking at this. Lint currently warns about libstd more than we'd like.

[nikomatsakis]

Status update 2020-11-02:

• Encountered false warnings as described here, trying to decide how to deal with them.

[nikomatsakis]

Status update 2020-11-17:

• Considered an inference change that could allow us to sometimes fall back to () for back-compat and other times ! (basically depending on whether the value "leaked out" into live code, sort of)

[nikomatsakis]

Status update 2021-04-06:

• @Mark-Simulacrum wrote up a detailed and useful report after doing some investigation. He and I also discussed the results and came to a preliminary consensus on the path forward.
• The upshot was:
  • We can't really leverage editions to avoid breakage so long as we want to update Infallible to !.
  • We can extend the hybrid proposal for never type fallback to cover cases where trait selection would cause further errors. This should allow us to land the never type fallback change without significant breakage.
  • The problem then is that the fallback proposal is kind of complex and still accepts code we arguably should not. We can deprecate that over time using warnings.
  • Once we've come to an algorithm or subset of fallback we are happy with, we can use an edition if desired to make a harder change.

[Mark-Simulacrum]

Status update 2021-05-13:

• @Mark-Simulacrum implemented the 'v2' hybrid algorithm proposed in the prior month in [WIP] Never type experiments rust#84573, but was met with some unexpected test failures
• @nikomatsakis and @Mark-Simulacrum discussed those test failures in an attempt to arrive at a new formulation of the algorithm, and developed what seemed like a promising solution. Unfortunately, during attempts to implement it, yet new test failures emerged; those have been lightly investigated but no next steps arrived at yet. The plan is to find some additional time to review and sync up on the results and implementation challenges.
• @lrh2000 has additionally been working on some related work related to polishing the particulars of when we choose to set ! and when not; that work may impact the fallback considerations as well.

[Mark-Simulacrum]

Status update 2021-06-28:

• [WIP] Never type experiments rust#84573 has finished the Crater run and showed 23 regressions. Niko and Mark discussed and wanted to try and nail down a "production" version of the implementation as a next step, which may resolve some of the regressions. The current implementation isn't well suited for landing into the mainline, was mostly intended for experimentation. The remaining regressions are low enough in quantity that otherwise moving forward is likely feasible.

[Mark-Simulacrum]

Another status update over the last week of progress; 2021-07-05:

• Implementation has been revised to something closer to landable (at least in Mark's opinion). Many of the regressions in the previous Crater run seem to be fixed in local testing; a new crater run is planned. Some known problems with the implementation, but it may make sense to talk about our plan for stabilizing (e.g., how much detail on the implemented algorithm we want, etc).
• Depending on (brief) discussion tomorrow's planning meeting, we may want a design meeting on the algorithm a few weeks out so that more updates on the algorithm can be prepared.