Repository navigation
Associated type behind a *mut unecessarily results in invariant subtyping #68375
Description
Consider the following code (playpen)
pub trait Data {
type Elem;
}
pub struct ViewRepr<A>(A);
impl<'a, A> Data for ViewRepr<&'a A> {
type Elem = A;
}
pub struct ArrayBase<D: Data> {
ptr: *mut D::Elem,
// ptr: *mut f32,
d: D,
}
pub fn cast_array_view<'shorter, 'longer: 'shorter>(
input: ArrayBase<ViewRepr<&'longer f32>>
) -> ArrayBase<ViewRepr<&'shorter f32>> {
input
}cast_array_view fails to compile with the first definition of ptr, and succeeds with the second, despite the two functions being apparently identical.
I think the reason this is happening is most likely related to the fact that subtyping of *mut pointers is invariant on the type of their parameter, and structs containing *mut T pointers are invariant with respect to T. Since D::Elem is being stored behind a *mut pointer rustc has decided that ArrayBase is invariant with respect to D, instead of D::Elem.
PS: Thanks to /u/Patryk27 on reddit for looking at this and pointing me in the direction of the variance docs.
Activity
RustyYato commentedon Jan 20, 2020
Using associated types always results in an invariant type bound, so that's where the invaraince is coming from. Also
*mut Tis invariant inT, as you noted, but this doesn't makeArrayBase<D>invariant inD, only invariant inD::Elem. But the fact that you usedD::Elemmakes it invariant inD.To get around this:
This allows Rust to reason about the variance of each parameter separately, which allows the code to pass
gmorenz commentedon Jan 20, 2020
Huh, ok. That leaves two questions
RustyYato commentedon Jan 20, 2020
Because there is no general way to figure out the lifetime relationships between the associated type and
Self. So invariance is the only safe variance.I'm not sure, I just came across this in much the same way you did. It should be added to the nomicon (and the reference while we're at it).
RustyYato commentedon Jan 20, 2020
Oh, you don't need the type alias. This works
This leads me to believe that we maybe could allow for a more lenient variance for associated types.
gmorenz commentedon Jan 20, 2020
I tend to agree with your conclusion that that suggests it would be possible to do better.
Actually trying to use that in real code (ndarray) results in me running into a different issue, which I believe is a version of #28895. I've added a minimized example to that issue.