Sometimes I wish that rustc had a database of small breaking changes that affect only a handful of crates, so that we could on the fly patch them going forward. Things like "we now correctly check for lifetimes in assoc types" can technically be a breaking change that affects a handful of crates, but I want to ensure that building a project from today in 15 years doesn't require a compiler tool chain from today.
I guess this is the windows backwards compatibility approach. #rust#rustlang
@ekuber At neo4j I called this the "we got addition wrong" problem.
What if Cypher had a bug that added 1 to every addition? Then users would need to -1 every result. Once we discovered it, it would mean that every codebase that had patched the issue would now be broken even though we fixed the issue.
I would argue that what you describe would be a compiler config, because from the user's perspective it's like a reverse experimental feature.
@ekuber That means you put the burden on the user to flag which (now corrected) behaviors they depend on and, as long as they are present in the compiler, the project will keep compiling.
I'm not sure the compiler should know which crates depend on certain behaviors. That feels wrong.
@ekuber Editions, in this context, would be collections of "feature flags", right? If so, that would require discipline on both sides. Not a deal breaker, of course, but perhaps a different approach.
@chrisg I guess so. The problem is the maintenance burden of alternative behavior for fundamental checks, but that's kind of what we signed up for with editions.
It could even be for providing specific errors instead of "just make it work", telling people what magic changes might be needed to patch the outdated library.
Add comment