3 ms·
I wonder if the new-edition approach could be done by interpreting pre-2024 code as if everything had a Leak bound. So instead of a not-Leak type being disallow
by amluto 3y ago
I wonder if the new-edition approach could be done by interpreting pre-2024 code as if everything had a Leak bound. So instead of a not-Leak type being disallowed when passed to a pre-2024 module, it would not pass type checking because everything in the pre-2024 module required Leak.
- jeff-davis 3y agoThe article addresses this: "However - and this is the big, enormous caveat of this section - this would rely on the compiler effectively implementing some kind of unbreakable firewall, to prevent a type that does not implement Leak from ever getting used with pre-2024 code."
- amluto 3y agoWhat I mean is: instead of having a “firewall” in the compiler, is there a way to interpret pre-2024 code such that it has correct but conservative Leak bounds? Then there would be more confidence that, if a mixed-edition program type-checks, then it’s correct.
- ComputerGuru 3y agoIt took me a minute, but the firewall is talking about the reverse direction of preventing post-2024 code without Leak being used in pre-2024 code.
- AndrewDucker 3y agoHow would it know the code was pre 2024?