# \[pre-rfc\] Stable features for breaking changes

**URL:** <https://internals.rust-lang.org/t/pre-rfc-stable-features-for-breaking-changes/5002>\
**Category:** language design\
**Created:** [March 26, 2017, 11:48am UTC](https://internals.rust-lang.org/t/pre-rfc-stable-features-for-breaking-changes/5002 "2017-03-26T11:48:39Z")\
**Posts on this page:** 1\
**Showing post:** 34

<div class="post-metadata">

**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\
**Post date:** [March 28, 2017, 9:43pm UTC](https://internals.rust-lang.org/t/pre-rfc-stable-features-for-breaking-changes/5002/34 "2017-03-28T21:43:42Z")

</div>

> [@tom.prince](#):
>
> One of the nice things about having granular control (and why a bunch of people were unhappy with the 2-\>3 transition) is that you can make the fixes for each change independently, and then test and deploy your code with just those changes. One of the big troubles with the 2-\>3 transition is that you had to fix your code for all of the changes at once.

This is an interesting point. I do hope though that we can make the upgrade fully automated. Indeed, in each of the examples that I gave, it would be possible to do a fully automatic -- and 100% semantically faithful -- transition, although it may do things you might not have done had you transitioned by hand.

This is fairly clear for the first few examples. But it's also true for the match ergonomics example. In retrospect I didn't fully appreciate this while writing the post and hence I didn't emphasize it. But naturally if the compiler is unsure whether the destructor should run earlier or later, it could just conservatively insert a `mem::drop` into the match (i.e., to select the current semantics):

```rust
match opt_v {
    Some(v) => {
        println!("{:?}", v);
        mem::drop(v); // forces `v` to be moved, even under the newer proposals
    }
    _ => ... 
}

```

You could imagine the transition tool leaving behind markers when it makes conservative choices of this kind, that you could go and remove at your leisure. For example maybe it would generate:

```rust
match opt_v {
    Some(v) => {
        println!("{:?}", v);

        // rustfix: The following line could be removed,
        // if it is not important for the destructor of `v`
        // to execute early.
        mem::drop(v); 
    }
    _ => ... 
}

```

---

_[View the full topic](https://internals.rust-lang.org/t/pre-rfc-stable-features-for-breaking-changes/5002)._