never type stabilization about lang-team

[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]

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.

[Mark-Simulacrum]

The initial set of patches landed on master in September. For October, the plan is to:

• Create an initiative repository - https://github.com/rust-lang/never-type-initiative/
• Prepare a written explainer, or two, with T-lang and community audience
  • RFC draft (https://github.com/rust-lang/never-type-initiative/blob/master/RFC.md) is written up, likely needs some more iteration
• Prepare a draft stabilization PR to assess current master's breakage to determine if there are blockers to stabilization
  • Crater results: rust-lang/rust#89630 (comment)

It's a little unlikely, but the hope is that we will also get a chance to:

• Prepare a blog post -- though likely not for immediate publication -- with the content from the community explainer, with a goal of getting feedback on our design.
• Start work on a "N year plan" for the future of the inference rules around ! (and perhaps more generally). Niko and I agreed that the current proposal for ! is not ideal, and we'd like to see something simpler -- and perhaps more easily understandable/implementable under different schemes than currently in the compiler.

I also discussed with @nikomatsakis whether an RFC makes sense as something to aim towards. We noted that the vast majority of changes related to never type that we've been iterating on are likely a little better suited to initiative and/or more internal discussion, since they're mostly just implementation details of the larger goal laid out in the RFC. We've already accepted RFC 1216 for the motivation and general shape of the feature, so that part is largely taken care of. It's also true that such an RFC -- or indeed any documentation in this area -- quickly is confronted with the relative lack of documentation for type inference as a whole as implemented in Rust today, so it's hard to describe ! inference as an "edit".

[Mark-Simulacrum]

Status update 2021-06-28:

• rust-lang/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]

Status update 2021-05-13:

• @Mark-Simulacrum implemented the 'v2' hybrid algorithm proposed in the prior month in rust-lang/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.

[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]

Closing in favor of rust-lang/never-type-initiative#1