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

Document auto traits implemented by the return types of async fn #65677

Open
Aaron1011 opened this issue Oct 21, 2019 · 2 comments
Open

Document auto traits implemented by the return types of async fn #65677

Aaron1011 opened this issue Oct 21, 2019 · 2 comments

Comments

@Aaron1011
Copy link
Member

@Aaron1011 Aaron1011 commented Oct 21, 2019

Currently, Rustdoc documents auto-trait impls for types, displaying them along with manually written impls. However, there is currently no way of telling what auto traits are implemented by the impl Future type returned by an async fn.

I'm not quite sure what the best way of displaying this is. We need to make it clear to users that the auto trait impls apply to opaque return type - not to the function itself, or to the underlying type returned by the future (e.g. the u8 in async fn foo() -> u8).

@nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Oct 22, 2019

It would be nice if whatever approach we use here also applies to impl Trait return types in general.

@jyn514
Copy link
Member

@jyn514 jyn514 commented Jan 7, 2021

cc @Darksonn , you were asking for something like this in rust-lang/rfcs#2963 (comment).

In retrospect I think this should be possible as long as there aren't name resolution errors or type errors in the body. That may work for tokio but it will definitely break for async-std (#75100).

@jyn514 jyn514 changed the title Doucment auto traits for async fn Document auto traits implemented by the return types of async fn Jan 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants