Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upBreaking Change in Vec::truncate drop order between 1.40 -> 1.41 #68709
Comments
This comment has been minimized.
This comment has been minimized.
fn truncate_with_old_drop_order<T>(vec: &mut Vec<T>, len: usize) {
while vec.len() > len {
vec.pop();
}
} |
This comment has been minimized.
This comment has been minimized.
|
@sfackler we can deal with the fallout ourselves, but the fact that we were hit by this means that others in the ecosystem that are also not open source might have been hit by this change in behavior. The question is whether that is acceptable breakage. |
This comment has been minimized.
This comment has been minimized.
|
Seem like it is specified in the guarantees section of the documentation for
Arguably this section only applies to |
This comment has been minimized.
This comment has been minimized.
[emphasis mine] |
This comment has been minimized.
This comment has been minimized.
|
Also relevant is RFC 1857: Stabilize drop order, which in retrospect is oddly unclear about precisely how this applies to library types. The RFC text explicitly states a drop order for However, AFAICT not a single comment in that thread ever raised the question of Language-lawyering aside, this is definitely more subtle and unclear than it ought to be, and there's room for improvement (honestly, I thought I'd just pull a quote out of 1857 and move on, but now I've been writing this comment for twenty minutes...). At the bare minimum, we need to sort out the apparent contradiction between Vec's current documentation and RFC 1857, and generally make our documentation around drops more explicit about when we mean a type's Because On the plus side, a quick skim and search of |
This comment has been minimized.
This comment has been minimized.
|
|
Context:
The commit that introduced the change.
The PR for the commit
Minimal repro can be found in the commit and the PR. At work we have a private internal crate that depended on this drop ordering. As we had not run the beta train we did not catch it until attempting to upgrade our stable version of rust to 1.41.0. Now while the behavior of the drop order was unspecified it has been stabilized.
I'm sure we can find a workaround for this at work, but I'm filing this issue as it brings up some interesting questions that I don't know if the libs team has ever taken an official stance on.
If the observable behavior changes but isn't specified is this a breaking change?
The API itself has not changed, but the drop order has changed. I'm of the opinion it is a breaking change even if it brings the API more in line with how slice drop order works, though talking to some friends they are of the opinion it is not a breaking change.
Anyways I wanted to file this issue to bring attention to this and maybe get a more clear ruling from the libs team on what they consider is and is not breaking change behavior. If more info is needed on why we needed this @estebank and I can probably give more specifics on this, though I don't think this is so much trying to fix a bug as it is determining whether a change should be reverted.
Thanks!😄