Remove async-trait in favor of impl trait and native async in impls about bb8 HOT 6 OPEN

Okay, it will be a while before I want to accept a bump to 1.75, probably when we hit 1.81 or 1.83 or some such?

from bb8.

No worries, it's not like async-trait is a seriously problematic dependency to get rid of.

from bb8.

Would this need an MSRV bump, and if so, to what version? This is just RPITIT, right? Why not use AFIT here?

I do think it would be nice to adopt a more direct API eventually and am open to a PR, but unsure about the timeline here. It feels a little silly to adopt RPITIT now only to move over to AFIT later?

from bb8.

Would this need an MSRV bump, and if so, to what version?

Yes, this would bump the MSRV to 1.75.

This is just RPITIT, right? Why not use AFIT here?

This is both, because they're compatible. RPITIT for the trait declarations to require Send futures, otherwise code that's generic over these traits has to assume !Send futures until RTN (return-type notation) comes around, which would be a PITA; impls can be written using AFIT.

I do think it would be nice to adopt a more direct API eventually and am open to a PR, but unsure about the timeline here. It feels a little silly to adopt RPITIT now only to move over to AFIT later?

Yeah, it would be a breaking change to move the declarations to AFIT later, but a very minor one because implementations wouldn't change at all, just code that's generic over these traits and assumes the returned futures are Send would have to use RTN or some equivalent once the Send requirement is removed from the trait decl (with or without switching from RPITIT to AFIT).

from bb8.

Okay, so... In half a year or a bit more. That's seems like a lot to me but I'm not here to start a debate over MSRV policies :)

Thanks for the fast responses!

from bb8.

Yes, sorry -- I know I am on the conservative side here -- and given that this is definitely a lower-priority project for me I really don't want to maintain two branches in parallel.

from bb8.