Comment by dwattttt
10 days ago
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.
They didn't special case this (in this way at least). You only need to specify the bounds relevant to this impl at this point.
It doesn't even have to be less constrained than the containing types definition. You can provide an impl with more constraints; for example, a type Q<T: Read + Write>, but impl Seek for Q<T: Read + Seek>
I thought only as constrained and more constrained is allowed, and less constrained is always an error. At least that's been my experience - if `Q<T: A>`, then I could never get `impl<T> Q<T>` working in any conditions until I added `where T: A`.
Do you happen to know the specific rules of when it's an error and when it's not?
1 reply →