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

extending the existing solver may worsen the transition #5

Open
lcnr opened this issue Feb 17, 2023 · 0 comments
Open

extending the existing solver may worsen the transition #5

lcnr opened this issue Feb 17, 2023 · 0 comments

Comments

@lcnr
Copy link
Owner

lcnr commented Feb 17, 2023

I am worried about improving the existing solver, either by reducing the amount of incorrect ambiguity or by adding new features. I personally would like to not stabilize any type system extensions until the new solver is used by default.

Any behavior of the old solver usable on stable has to either be maintained by the new solver or we have to accept a breaking change when switching solver. It is very easy to implement behavior in the old solver which is cannot be emulated by the old solver, meaning that switching solvers will have to break this behavior.

Probably the best example here is At::define_opaque_types. This function changes the way type relations treat opaque types. The existing trait solver has code paths which enable this while other paths don't. These paths will end up merged in the new solver. We cannot support the current behavior without fairly big changes to how the new solver works, increasing its complexity and worsening its caching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant