[pre-rfc] Stable features for breaking changes

language design
34

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):

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:

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); 
    }
    _ => ... 
}
1 Like