It should be feasible to write a simple script -- "restore_old_box_behavior.pl", say -- that replaces any instances of &'x Box<Trait> with &'x Box<Trait + 'x> throughout a codebase. In practice, that's probably better than &legacy[], because it takes the same amount of time, but it will work until Rust 2.0 without any versioning guarantees. The other big downside of versioning is that over time it significantly increases the surface area for an alternate Rust implementation to support, when ideally we should start to see such implementations pretty soon. It's also possible where this newly-introduced error occurs, even in an old, unmaintained codebase, for rustc to suggest the appropriate change in a compiler error message.
The other advantage of using a script instead of introducing #legacy[] is that (because of the extra work involved) it continues to send the message that breaking changes will be extremely few and far between. If #legacy[] is part of rust, you're telling people it's unstable, one way or the other.
I'm cautiously in favor of this change because:
-
all of the old behavior is still fully accessible by merely changing type annotations
-
such a script will always fix any code that depends on the old behavior
- as long as said code does not link to code that depends on the new behavior
In this case, the caveat is hilariously unlikely; even so, only a little more type-annotation-juggling will probably fix it. You could probably refer complainants to this part of the 1.0 blog post:
We reserve the right to fix compiler bugs, patch safety holes, and change type inference in ways that may occasionally require new type annotations.
Type aliasing isn't quite type inference, but it's close enough to fool all but the most intransigent type-theorists. A slightly weaker (but still very strong) stability guarantee that this does not violate is:
no semantic changes after 1.0 (except bugfixes)