Merging futures-timer into this repository.

[carloskiki]

I believe the futures-timer crate is now unmaintained since it is housed under the async-rs group (which stopped maintaining async-std).

It would be awesome if we could fork it in this repository. I find it hard to believe that this is the only timer library which does not bring extra dependencies, but I simply can't find another one. I hope we can keep maintaining it for this reason.

I can open a PR if the maintainers are in favour of this.

[seanmonstar]

I'm no longer a maintainer here, but generally (IMO) there isn't enough maintainer time for what already is here, and less and less from wg-async, so I'd find it hard to adopt another crate into this repo.

That said, you could always fork the timers crate and maintain it. That's the beauty of open source :)

[taiki-e]

I'm effectively the only current maintainer of futures-rs (although wg-async also has access), but since I'm also involved in the maintenance of tokio and smol, I'm honestly not very interested in adding and maintaining new utilities that are also already provided by tokio and smol, to futures-rs. (Aside from the case of adding methods to extension traits.)

Also note that futures-timer has been almost unmaintained for the last five years, as is obvious from the commit history.

Therefore, I would recommend the use of tokio or smol (or async-io which actually implements smol's timer) timers.

the only timer library which does not bring extra dependencies

I'm not claiming that this particular library is problematic, but in my experience, you usually have to be very careful with async-related libraries that have no dependencies (especially those that claim it as an advantage). This is especially true when there is unsafe code around pinning.

It is very hard to manually write unsafe code around pinning (instead of using pin-project/pin-project-lite), and even people familiar with async Rust or unsafe Rust can easily write unsound or error-prone or inefficient code. And those who are not enough aware of this fact tend to claim “no dependencies at all, unlike other (well-reviewed) crates” as an advantage of their crate.

FYI, the following is a non-exhaustive list of such mistakes that I have found in my reviews:

#2452 (review)
#2851 (comment)
rust-lang/rust#111347 (review)
tokio-rs/tokio#2612
async-rs/async-std#903
smol-rs/event-listener#50 (comment)
smol-rs/async-lock#36 (comment)
smol-rs/futures-lite#15 (comment)
ardaku/pasts#3

(futures-micro and pasts linked in the last two are not so well-known, but they ware precisely the ones that “claim the no dependencies as an advantage, and there actually have been unsoundness regarding pinning in the past (already fixed AFAIK)”.)