async fn in trait should require async fn in impl
#102745
Assignees
Labels
F-async_fn_in_trait
Static async fn in traits
Comments
|
Assigning to @ComputerDruid who expressed interest in working on this. |
|
@rustbot assign @ComputerDruid idk if that works, the github UI doesn't let me assign to you 😝 |
|
ugh lol |
|
@rustbot claim |
|
Should it be satisfied with |
|
I think not for now, and certainly not without the user enabling the |
matthiaskrgr
pushed a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 28, 2022
- Add comment to some tests that will break when rust-lang#102745 is implemented - Mark a test with known-bug - Delete duplicate test
ComputerDruid
added a commit
to ComputerDruid/rust
that referenced
this issue
Dec 9, 2022
As a workaround for the full `#[refine]` semantics not being implemented yet, forbit returning a concrete future type like `Box<dyn Future>` or a manually implemented Future. `-> impl Future` is still permitted; while that can also cause accidental refinement, that's behind a different feature gate (`return_position_impl_trait_in_trait`) and that problem exists regardless of whether the trait method is async, so will have to be solved more generally. Fixes rust-lang#102745
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 14, 2022
…ler-errors Ensure async trait impls are async (or otherwise return an opaque type) As a workaround for the full `#[refine]` semantics not being implemented yet, forbit returning a concrete future type like `Box<dyn Future>` or a manually implemented Future. `-> impl Future` is still permitted; while that can also cause accidental refinement, that's behind a different feature gate (`return_position_impl_trait_in_trait`) and that problem exists regardless of whether the trait method is async, so will have to be solved more generally. Fixes rust-lang#102745
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 15, 2022
…ler-errors Ensure async trait impls are async (or otherwise return an opaque type) As a workaround for the full `#[refine]` semantics not being implemented yet, forbit returning a concrete future type like `Box<dyn Future>` or a manually implemented Future. `-> impl Future` is still permitted; while that can also cause accidental refinement, that's behind a different feature gate (`return_position_impl_trait_in_trait`) and that problem exists regardless of whether the trait method is async, so will have to be solved more generally. Fixes rust-lang#102745
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 15, 2022
…ler-errors Ensure async trait impls are async (or otherwise return an opaque type) As a workaround for the full `#[refine]` semantics not being implemented yet, forbit returning a concrete future type like `Box<dyn Future>` or a manually implemented Future. `-> impl Future` is still permitted; while that can also cause accidental refinement, that's behind a different feature gate (`return_position_impl_trait_in_trait`) and that problem exists regardless of whether the trait method is async, so will have to be solved more generally. Fixes rust-lang#102745
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 15, 2022
…ler-errors Ensure async trait impls are async (or otherwise return an opaque type) As a workaround for the full `#[refine]` semantics not being implemented yet, forbit returning a concrete future type like `Box<dyn Future>` or a manually implemented Future. `-> impl Future` is still permitted; while that can also cause accidental refinement, that's behind a different feature gate (`return_position_impl_trait_in_trait`) and that problem exists regardless of whether the trait method is async, so will have to be solved more generally. Fixes rust-lang#102745
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
For now, we've decided that an
async fn() -> Tin a trait should not be satisfied by afn() -> TypewhereType: Future<Output = T>until we at least hammer out how#[refine]is gonna work, etc.So let's just do a HIR check that the signatures are compatible.
The text was updated successfully, but these errors were encountered: