Twitter | Pretraživanje | |
bblum chesed yibaneh 26. lis
Odgovor korisniku/ci @nikomatsakis
good read!! it's nice to see where the type system's current limitations are and how they move over time. looks pretty thorny...
Reply Retweet Označi sa "sviđa mi se"
bblum chesed yibaneh 26. lis
Odgovor korisniku/ci @nikomatsakis
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?
Reply Retweet Označi sa "sviđa mi se"
Michael Watzko 26. lis
Odgovor korisniku/ci @nikomatsakis
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
Reply Retweet Označi sa "sviđa mi se"
Vincent Isambart 26. lis
Odgovor korisniku/ci @nikomatsakis
Nice write-up! A few minor fixes though: s/associaed/associated/ s/imagine that had/imagine that we had/
Reply Retweet Označi sa "sviđa mi se"
Alexey Zatelepin 26. lis
Odgovor korisniku/ci @nikomatsakis
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.
Reply Retweet Označi sa "sviđa mi se"
pseudomorphism 30. lis
Odgovor korisniku/ci @nikomatsakis
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 )
Reply Retweet Označi sa "sviđa mi se"