Skip to content

extending the existing solver may worsen the transition #5

@lcnr

Description

@lcnr

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.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions