3 ms·
I see. Would that be such a disaster under your proposal? Original code is: async fn f<'a>(r: &'a i32) -> i32 { ... *r ... } Having some callers future{ f(
by jules 7y ago
I see. Would that be such a disaster under your proposal? Original code is:
async fn f<'a>(r: &'a i32) -> i32 { ... *r ... }
Having some callers future{ f(&i) }.await().
Now the new caller comes in, so we add a function f_future:
fn f_future<'a>(r: &'a i32) -> impl Future<Output = i32>
let i = *r;
async { ... i ... }
}
The new caller uses f_future and the old callers keep using f. To prevent duplication we can factor out ... i ... into a function g(i) and do g(*r) in the async fn f. The other callers can migrate from future{ f(&i) }.await() to f_future(&i).await() over time.
It's not as ideal as not having to change the signature at all, but signature changes can be dealt with. Or is this a big problem with OS threads?
- Rusky 7y agoI agree, there's plenty of ways to work around it, and I'd prefer any of them to the syntactic mess we're in now. I'm not the one making the decisions, though. :)