Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

never type stabilization #60

Closed
nikomatsakis opened this issue Oct 12, 2020 · 10 comments
Closed

never type stabilization #60

nikomatsakis opened this issue Oct 12, 2020 · 10 comments
Labels
lang-initiative An active lang team initiative T-lang

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Oct 12, 2020

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

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 nikomatsakis added lang-initiative An active lang team initiative T-lang labels Oct 12, 2020
@nikomatsakis
Copy link
Contributor Author

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
Copy link
Contributor Author

Status update 2020-10-26:

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

@nikomatsakis
Copy link
Contributor Author

Status update 2020-11-02:

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

@nikomatsakis
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

Mark-Simulacrum commented Oct 6, 2021

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

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

@nikomatsakis
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lang-initiative An active lang team initiative T-lang
Projects
None yet
Development

No branches or pull requests

2 participants