Conversation
| ### Will these fixes break my code? | ||
|
|
||
| They might, but only if your code was relying on unsound behavior—and you'll get advance warning. Soundness fixes land with future-compatibility warnings first, giving crate authors time to update before the old behavior is removed. | ||
| They might, but only if your code was relying on unsound behavior and you'll get advance warning in that case. Soundness fixes causing non-trivial breakage land with future-compatibility warnings first, giving crate authors time to update before the old behavior is removed. |
There was a problem hiding this comment.
i was actually just about to open something about this wording. "but only if your code was relying on unsound behavior" seems dubious to promise.. We definitely would like for this to be the case but I would expect there to be soundness fixes which have additional fallout than crates which actually relied on unsoundnesses
| * **Zero means zero.** Not "fewer bugs" or "the important ones." The goal is to fix every known soundness issue, however obscure. | ||
|
|
||
| * **Migrate, don't break.** Soundness fixes must use future-compatibility warnings to give the ecosystem time to adapt. Breakage is acceptable only where code was relying on unsound behavior, and even then the transition should be gradual. | ||
| * **Migrate, don't break.** Breakage is acceptable only where code was relying on unsound behavior, and even then the transition should be gradual. If it causes non-trivial breakage, fixes must use future-compatibility warnings to give the ecosystem time to adapt. |
There was a problem hiding this comment.
similarly I don't think "acceptable only where code was relying on unsound behaviour" is necessarily true. I would expect assumptions on binders and checking wf of stuff under binders to have fallout which is not strictly "your code is unsound" and I would expect us to do a lot to try and minimize the breakage, but I don't think this is a hard rule
3 participants
r? @nikomatsakis
Rendered