No, the compiler relies (only) on stuff being Sync to impl Sync. There is additionally an impl of &T: Send for T:Sync.
-
-
Replying to @ManishEarth @glaebhoerl
How should I interpret the highlighed sentence, then?pic.twitter.com/8XdgOfomcM
1 reply 0 retweets 0 likes -
Replying to @H2CO3_iOS @glaebhoerl
"if you follow through", this is a combination of features interacting together
2 replies 0 retweets 1 like -
MutexGuard contains an &Mutex. Mutex itself is Sync+Send when T is Send, due to an impl. So is &Mutex, then. So is MutexGuard, then.
1 reply 0 retweets 1 like -
rustc only inferred the second two steps. The rest was explicitly provided to it; we *told* the compiler "T: Send => Mutex<T>: Sync+Send"
2 replies 0 retweets 0 likes -
relevant line: unsafe impl<T: ?Sized + Send> Sync for Mutex<T> { }
2 replies 0 retweets 2 likes -
Replying to @Gankra_ @ManishEarth and
It really does seem like using `PhantomData` would have made more sense than opting out of the autotrait impl
1 reply 1 retweet 1 like -
PhantomData<&mut T> I suppose? Perhaps. I wonder how the variance of that works out. Actually, there's a chance variance is wrong there.
1 reply 1 retweet 1 like -
Yes. The variance shouldn't change since it'll still have the `&Mutex<T>` reference with the same lifetime.
1 reply 0 retweets 0 likes -
No, but.. If the T itself has a lifetime, we need MutexGuard to be semantically equivalent to &mut T, not &T, so that it's invariant.
1 reply 0 retweets 0 likes
Wouldn't that imply that the current variance is probably broken?
-
-
Yes. I'm looking into it.
1 reply 0 retweets 0 likes -
Replying to @ManishEarth @sgrif and
Ok, this *does* fail to compile, which indicates that stuff is working correctly https://is.gd/MgwR3C .
1 reply 1 retweet 1 like - 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.