Below is my subjective opinion on how to better motivate readers towards NonNull (Section 7.2: Variance and Subtyping). I'm an intermediate in rust so maybe someone with more knowledge can correct me if I'm wrong.
While going through the chapter for the first time, I was extremely confused as to why do we suddenly care about Variance when there was no mention of it in the previous chapters. There is at least one such case of a reader feeling the same way. While Aria explains it brilliantly, it requires the reader to push through this initial confusion.
I believe that we could better motivate the situation by talking about the ergonomic difficulties tied with using *mut Node<T> (such as using constant checks to ensure it is not null before performing relevant operations) and how nullability has become an implicit contract than explicit one.
Then, we'd guide the reader towards NonNull as superior alternative - we'd get better ergonomics, explicit nullability and null pointer optimization, something we really cared about at the start of the book.
We could then show some unsound behavior due to the covariant nature of NonNull and then introduce the concept of variance to explain how NonNull is covariant over T whereas *mut T was invariant. This would naturally help us introduce PhantomData to bring back the invariance to avoid potentially unsound behavior.
Below is my subjective opinion on how to better motivate readers towards
NonNull(Section 7.2: Variance and Subtyping). I'm an intermediate in rust so maybe someone with more knowledge can correct me if I'm wrong.While going through the chapter for the first time, I was extremely confused as to why do we suddenly care about Variance when there was no mention of it in the previous chapters. There is at least one such case of a reader feeling the same way. While Aria explains it brilliantly, it requires the reader to push through this initial confusion.
I believe that we could better motivate the situation by talking about the ergonomic difficulties tied with using
*mut Node<T>(such as using constant checks to ensure it is not null before performing relevant operations) and how nullability has become an implicit contract than explicit one.Then, we'd guide the reader towards
NonNullas superior alternative - we'd get better ergonomics, explicit nullability and null pointer optimization, something we really cared about at the start of the book.We could then show some unsound behavior due to the covariant nature of
NonNulland then introduce the concept of variance to explain howNonNullis covariant overTwhereas*mut Twas invariant. This would naturally help us introducePhantomDatato bring back the invariance to avoid potentially unsound behavior.