Should we remove FutureObj

[leaxoy]

We should change Spawn.spawn_obj to Spawn.spawn_boxed which take a BoxFuture as param, and deprecate FutureObj, then remove it in future.

[Nemo157]

The point of having FutureObj is to make Spawn no_std compatible (by allowing you to implement UnsafeFutureObj for your own Boxlike types). Maybe this is not a useful goal and should be abandoned.

In terms of how this affects usability, there's two sides to look at, users spawning futures and implementors of an executor:

For users spawning futures they should currently be going via SpawnExt::spawn instead of using Spawn::spawn_obj directly, this allows spawning BoxFuture, but causes it to be double-boxed. It would be possible to add a SpawnExt::spawn_boxed which avoids the double-boxing, or wait for specialization to allow specializing SpawnExt::spawn for UnsafeFutureObj and directly convert them into FutureObj.

For implementors of an executer maybe there should be a separate SpawnBox trait which has a blanket impl Spawn for impl SpawnBox, similar to how we provide an ArcWake trait that you're expected to implement instead of directly implementing UnsafeWake. That way std-only executors don't ever have to touch FutureObj. (I think it would be possible for this implementation to take a FutureObj, check whether it is actually a BoxFuture and turn it into the BoxFuture for spawning, otherwise wrap the FutureObj into another Box).

This is all just workarounds until the real solution of being able to spawn by unsized rvalue exists, the executor is in most cases already allocating some structure for the task for its own wake-tracking, with unsized rvalues it will be able to directly place the spawned future into this structure and avoid the double-indirection that's inherent to any kind of boxed spawning.

[leaxoy]

Thanks for your explain, now should I keep this open for tracking?

[taiki-e]

Given that SpawnExt requires alloc, I don't think there is much benefit to use Spawn trait in a no-alloc environment. (Perhaps it more makes sense to add something like tokio 0.1's TypedExecutor.)