Comment by dwattttt
11 days ago
Even if the bounds are the same on the struct and the impl, it's still true that placing bounds on the Drop impl means it's not implemented for all T (just all T that also satisfy Q).
You also don't have to place those bounds on the Drop impl just because they're on Q, that's not an error.
The Drop isn't implemented for T at all. It's only implemented for Q<T>. And it's implemented for all Q<T>, in the sense that for every value of type Q<T>, this Drop impl applies.
And I'm still not any closer to understanding what the bug is about.
Sorry, yes. I mean that Drop isn't implemented for all Q<T>, just all Q<T> where T meet the bounds of legally constructing Q. I note the difference because you can write a Drop impl with no bounds on T, and I believe it would not be able to trigger the bug.
This is so stupid. One, why did they make Drop special in this one way when every other trait impl has to repeat all bounds exactly to be valid? Two, the bug isn't even in the Drop impl, it's in the assignment on line 11. q.0 can never be Some(&l) because &l is not 'static. The Drop impl is there just to show the invalid read, but the bug doesn't require it, it's just as wrong for types that don't impl Drop.
3 replies →