reimplement purity check in a more principled way #3490
Labels
A-lifetimes
Area: Lifetimes / regions
A-type-system
Area: Type system
C-cleanup
Category: PRs that clean code up or issues documenting cleanup.
Milestone
Purity checking is currently done via some rather ad-hoc rules in borrowck. The actual effect system that's being enforced is a BIT subtle. I would prefer to implement a separate purityck later that is modeling the underlying effect system more directly. This would not only be less complex in the implementation, it would give me more confidence we are enforcing the rules we want to enforce.
Here is an example of some code which may or may not be safe:
To answer whether it's safe requires me to (1) reconstruct the mental model of purity I had in mind; (2) check whether this conforms. I'm deferring step (1) for the moment until I get back to this bug.
Here are some further notes I wrote down at some point regarding how our rules map to an underlyling effect system.
The text was updated successfully, but these errors were encountered: