Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement {Arc, Rc}::downcast #1340

Closed
apasel422 opened this issue Oct 27, 2015 · 8 comments
Closed

Implement {Arc, Rc}::downcast #1340

apasel422 opened this issue Oct 27, 2015 · 8 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@apasel422
Copy link
Contributor

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/.

@Gankra
Copy link
Contributor

Gankra commented Oct 27, 2015

For those who don't want to dig through some source:

impl Arc<Any> {
    pub fn downcast<T>(self) -> Result<Arc<T>, Self> where T: Any;
}

@glaebhoerl
Copy link
Contributor

Could we do this generically (one impl, instead of one per smart pointer type) if we had HKT? (And if we don't?)

@seanmonstar
Copy link
Contributor

Don't forget OIBITs... impl Arc<Any + send>, impl Arc<Any + Send + Sync>, etc...

@apasel422
Copy link
Contributor Author

@seanmonstar Thanks for pointing that out. Do we need all combinatoric possibilities of {'static, Send, Sync}?

@Gankra
Copy link
Contributor

Gankra commented Oct 28, 2015

I believe if proper trait object subtyping (or just coercions...?) was implemented, this would be a non-issue.

@nrc nrc added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Aug 19, 2016
@mbrubeck
Copy link
Contributor

mbrubeck commented Feb 9, 2018

<Rc<Any>>::downcast was implemented in rust-lang/rust#44273.

The Arc method hasn't been implemented yet because it needs extra Send or Sync bounds to be useful.

@bluss
Copy link
Member

bluss commented 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
Copy link
Contributor

Centril commented Oct 7, 2018

This is implemented for both types, so I'm closing this.

@Centril Centril closed this as completed Oct 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

8 participants