|
@nikomatsakis | |||||
|
New #rustlang blog post: Why async fn in traits are so hard smallcultfollowing.com/babysteps/blog…
|
||||||
|
||||||
|
bblum chesed yibaneh
@bblum0
|
26. lis |
|
good read!! it's nice to see where the type system's current limitations are and how they move over time. looks pretty thorny...
|
||
|
|
||
|
bblum chesed yibaneh
@bblum0
|
26. lis |
|
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?
|
||
|
|
||
|
Michael Watzko
@kellerkindt
|
26. lis |
|
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
|
||
|
|
||
|
Vincent Isambart
@vincentisambart
|
26. lis |
|
Nice write-up! A few minor fixes though:
s/associaed/associated/
s/imagine that had/imagine that we had/
|
||
|
|
||
|
Alexey Zatelepin
@ztlpn
|
26. lis |
|
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.
|
||
|
|
||
|
pseudomorphism
@pseudo_morphism
|
30. lis |
|
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 github.com/tokio-rs/traci…)
|
||
|
|
||