Open compiler-errors opened 1 year ago
hey
Is there a way to use this the following way?
#![feature(async_fn_in_trait)]
#![feature(return_type_notation)]
use std::future::Future;
trait Inner: Send + Sync {
async fn do_async(&self);
}
trait Outer {
type In: Inner<do_async(): Send>;
}
fn foo<T>(inner: T::In) -> impl Future + Send
where
T: Outer,
{
async move {
inner.do_async().await;
}
}
somewhat related: we may want to change async
functions to return impl IntoFuture
instead of impl Future
so we can eventually replace Pin
with !Move
as outlined here -- having Send
bounds everywhere on the direct return type which would be impl IntoFuture
with that change but not the Future
type makes that edition change much more difficult, so imo we should consider alternatives, one of which is somehow making Trait::my_async_fn(..): Send
also imply the Future
is Send
either by adding that bound as a desugaring or requiring the new Pin
-less IntoFuture
to have Self: Send
imply Self::IntoFuture: Send
Sorry, I didn't see the RFC until it was merged. Just a quick comment for your consideration.
The chosen syntax might be confusing bounds on the function itself with bounds on the return type of the function? This could come back and bite future Rust if trait bounds are made possible for functions (as effects for example):
fn restricted_function<T: Foo>()
where
T::method(..): NoPanic + NoAlloc // Bounds on the function itself
In contrast to:
fn restricted_return_type<T: Foo>()
where
T::method(..) -> Send + 'static // Bounds on the return type
The parentheses clearly indicates it's the eval result (output, return type) of the function, not the function itself.
This is a tracking issue for the feature return type notation specified in rust-lang/rfcs#3654. The feature gate for the issue is
#![feature(return_type_notation)]
.About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
where T::method(): Send
) https://github.com/rust-lang/rust/pull/129629Unresolved questions
T::foo(..)
notation as a standalone type create a confusing inconsistency with-> ()
shorthand?Experimental results
Part of the goal of the experimental process is to identify benefits but also concerns that need to be addressed in the RFC.
typeof
syntax.Implementation history
109010