You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While the crate currently supports most control-flow interacting effects, such as break, continue, (early) return and ?, there is still one special control-flow transformation that needs to be supported: async / .await.
Currently, the callback needs to return a dyn Future since otherwise Rust gets confused with HRTB involving a higher-order lifetime, an infinite set of possible impl Futures returned by the callback, and the fact all the futures need to resolve to the same type R, independent of the 'local lifetime.
In practice, this requires a helper wrapper around the return value of the callback, since otherwise the for<'any> higher-order bound over restrains in the region of big lifetimes, thus preventing the provided callback / future from borrowing anything, which would totally obliterate the usability and thus purpose of this pattern.
While the crate currently supports most control-flow interacting effects, such as
break
,continue
, (early)return
and?
, there is still one special control-flow transformation that needs to be supported:async
/.await
.That is,
ought to unsugar to something along the lines of:
Currently, the callback needs to return a
dyn Future
since otherwise Rust gets confused with HRTB involving a higher-order lifetime, an infinite set of possibleimpl Future
s returned by the callback, and the fact all the futures need to resolve to the same typeR
, independent of the'local
lifetime.In practice, this requires a helper wrapper around the return value of the callback, since otherwise the
for<'any>
higher-order bound over restrains in the region of big lifetimes, thus preventing the provided callback / future from borrowing anything, which would totally obliterate the usability and thus purpose of this pattern.See this post of mine, especially the
Hack
wrapper, to better see why.Finally, it would be neat if the
dyn Future
relied on a stack allocation of some form rather than a heap-allocation:Pin<&'local mut dyn Future>
The text was updated successfully, but these errors were encountered: