Remove spawning from task::Context

[cramertj]

r? @aturon

cc rustasync/team#56

[seanmonstar]

With the remove of FutureObj and co, unless arbitrary_self_types has made Future object-safe, there's no longer a way to have Future trait objects, right?

[Nemo157]

Is the plan to provide a Spawn trait and FutureObj etc. in futures, or just drop them from the "core" abstractions?

[cramertj]

@seanmonstar

With the remove of FutureObj and co, unless arbitrary_self_types has made Future object-safe, there's no longer a way to have Future trait objects, right?

We'll continue to provide these types inside the futures crate, but they no longer need to be part of the standard library.

@Nemo157

Is the plan to provide a Spawn trait and FutureObj etc. in futures, or just drop them from the "core" abstractions?

Yup-- everything that is being removed from here will reappear in the futures crate.

[aturon]

This looks great, nice simplification.

@bors r+

[bors]

📌 Commit 1b00f0b has been approved by aturon

[Thomasdezeeuw]

Isn't this a bit quick since the discussion is still going in rustasync/team#56? I'm for this change, but not everbody is.

[cramertj]

@Thomasdezeeuw The point of having the current std API is to experiment with the intended design-- any design (even the current one) needs to go through a real RFC before stabilization. I think the conversation in rustasync/team#56 has turned up enough motivating factors that we should give this approach a shot. If it doesn't work out or the RFC process resolves to a different design, then we can change it. If you think there's a solid reason we shouldn't do this (to the point that it's not worth trying) please leave a comment on rustasync/team#56 so we can take that into account!

[Ekleog]

@cramertj I think I put forward some arguments against rushing this in rustasync/team#56 , that were only answered by “don't do this, change your API” (which I don't really consider a valid resolution). Basically, this without any solution to rustasync/team#7 is breaking the (my? maybe I'm the only one here who actually has a use case for access to the default spawner from library code…) world without any other way to do the same thing.

On the other hand, this change can happen at any time until the RFC. Is there really a need to rush this forward before solving rustasync/team#7?

[bors]

⌛ Testing commit 1b00f0b with merge 2287a7a...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: aturon
Pushing 2287a7a to master...

[cramertj]

Is there really a need to rush this forward before solving rustasync/team#7?

@Ekleog IMO one of the best steps we can take towards solving rustasync/team#7 is to actually get experience using both APIs, which this change allows us to do. Additionally, I'd like to open an RFC for futures-in-std soon, and it'd be best if we could say we'd successfully tested and been using the same API as the one being RFC'd.

[Ekleog]

@cramertj I'm not really sure I understand whether you already meant it, but… it sounds to me like the potential hooks mentioned by rustasync/team#7 would likely need to be implemented in the Executor trait? Which would mean a futures-in-std RFC would still be blocked on experimenting with the outcome of rustasync/team#7 anyway.