How often do you want non-send futures?

[Nemo157]

@nikomatsakis

If we stick with the current design

Which specific design are you referring to here? It's been a long time since I remember seeing a full sketch of how async fn in traits could work. Wow, searching back for it the last major thread on this is over a year old:

Pre-Pre-RFC: async methods & bounding async fns

Motivation The async fn RFC (in the process of being implemented) has two limitations: It only supports free async functions, not async trait methods (which allows async functions to play a role in our polymorphism system). It does not provide a way to require that your async fn’s future implements a trait like Send. This can often be very important. These two problems were sort of related. This pre-RFC is a sketch of how they could be solved. The main insight is that we can take inspiration…

There are (hopefully) soon to be implemented features (GATs + existential types) that will allow at least basic usage of async in traits, these don't currently encounter the same issue because you can choose whether to add the Send bound to the associated type:

trait Process {
  type ProcessFuture<'a>: Future<Output = ()> + Send + 'a;

  fn process(&self) -> Self::ProcessFuture<'_>;
}

impl Process for () {
  type ProcessFuture<'a> = impl Future<Output = ()> + Send + 'a;

  fn process(&self) -> Self::ProcessFuture<'_> {
    async { println!("processing"); }
  }
}

fn foo<P: Process>(p: P) {
    let x = spawn(p.process());
}

The issue arises only once a new feature is added to allow the async fn syntax in traits (whether it's direct sugar for the pattern above, or something different but similar).