[shiny future] async in traits

[nikomatsakis]

Here's a start of a take on how I think that traits and async fn could work. This isn't complete yet, there are some details that I don't know how to make fit, particularly around trait objects. I'd also like to leave some notes in the design docs and FAQs.

[pickfire]

What if the original library expected it to be sync but then people want to use async within it? Do they need to provide another function with _async for it and duplicate the common methods? Let me give an example which I have faced.

https://docs.rs/rustls/0.19.1/rustls/trait.ResolvesServerCert.html

ResolvesServerCert is a trait which existed for quite some time, the original intention (I guess) is the author expects the users to pre-load the certs before running that function. But in my case, I want to do some async stuff when the resolve function runs, say I want to register a certificate with lets encrypt using ACME.

Should they provide two versions - one for sync and one for async? Internally, they will call one of it, do they wrap the async version with the sync version since users will only provide one of them so they only call the sync version like how it is done currently? And if they did (without using feature gates), doesn't that impose additional libraries for the users that only use the sync version?

The current version that I did is just wrapping bunch of async methods using block_in_place everywhere since there is a lock to be held (and that is an async lock) so there are like 5 of them, and the call to lets encrypt also needs to be wrapped with block_in_place since I did that using a async function.

[nikomatsakis]

Good questions, @pickfire -- I don't know the answers, but I'll ponder it. I was thinking about how I need to add more vignettes to this story to cover lots of different scenarios. There's a lot going on here. I think there may well want to be a few different versions, too.

[nikomatsakis]

Closing in favor of #222