You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think this is possible to do safely, as it is essentially the inverse operation of CoerceUnsized. See an example implementation at https://github.com/apasel422/ref_count/.
What do you think of simply implementing all combinations, instead of us guessing up front which ones are useful? That would be: Arc<Any>, Arc<Any + Send>, Arc<Any + Sync>, Arc<Any + Send + Sync>.
Activity
Gankra commentedon Oct 27, 2015
For those who don't want to dig through some source:
glaebhoerl commentedon Oct 27, 2015
Could we do this generically (one impl, instead of one per smart pointer type) if we had HKT? (And if we don't?)
seanmonstar commentedon Oct 27, 2015
Don't forget OIBITs...
impl Arc<Any + send>,impl Arc<Any + Send + Sync>, etc...apasel422 commentedon Oct 28, 2015
@seanmonstar Thanks for pointing that out. Do we need all combinatoric possibilities of
{'static, Send, Sync}?Gankra commentedon Oct 28, 2015
I believe if proper trait object subtyping (or just coercions...?) was implemented, this would be a non-issue.
mbrubeck commentedon Feb 9, 2018
<Rc<Any>>::downcastwas implemented in rust-lang/rust#44273.The
Arcmethod hasn't been implemented yet because it needs extraSendorSyncbounds to be useful.bluss commentedon Feb 9, 2018
What do you think of simply implementing all combinations, instead of us guessing up front which ones are useful? That would be:
Arc<Any>, Arc<Any + Send>, Arc<Any + Sync>, Arc<Any + Send + Sync>.Centril commentedon Oct 7, 2018
This is implemented for both types, so I'm closing this.