good read!! it's nice to see where the type system's current limitations are and how they move over time. looks pretty thorny...
New #rustlang blog post: Why async fn in traits are so hard http://smallcultfollowing.com/babysteps/blog/2019/10/26/async-fn-in-traits-are-hard/ …
-
-
-
btw, for complication 1a, would supporting the non-async/non-generic subset of `impl Trait` returns as associated types be easy? i'd think it'd require either a little syntax magic to avoid naming the type, or making it break object safety, but no further trickery, no?
End of conversation
New conversation -
-
-
Hmm, what about `dyn async fn` marking functions returning boxed futures and `async fn` returning impl futures? In traits one could then (for now) only support boxed futures without blocking a solution to impl futures. It would also be consistent with the current usage of dyn
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Nice write-up! A few minor fixes though: s/associaed/associated/ s/imagine that had/imagine that we had/
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Stupid question: what if bounds on returned future types were required to be part of the trait method definitions (I guess that's what async-trait offers for the Send bound)? Sure that's less flexible but probably easier for users of the trait impls.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
thanks for the post! I was wondering if you have any thoughts on fixing macro compatibility issues caused by the interaction of `async-trait` and other function-level macros (eg tracing's `instrument`, which branches based on a function's async-ness, see https://github.com/tokio-rs/tracing/issues/399 …)
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.