Update if-watch requirement from 0.1.8 to 0.2.0

[dependabot]

Updates the requirements on if-watch to permit the latest version.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[romanb]

I updated libp2p-tcp, so once #1977 is merged (which does the update for libp2p-mdns), this PR should be ready. It is a bit awkward though that IfWatcher is now polled as a Future, as it is polled again after it is Ready and the API contract of std::future::Future states "Once a future has finished, clients should not poll it again.". So this looks wrong on first sight to someone reading the code. Is there a reason IfWatcher does not implement Stream rather than Future so we can use Stream::poll_next() @dvc94ch?

[dvc94ch]

well, that is what I did initially. one thing I don't like about that is that it has to return an Option and every caller needs to handle the None case that never happens. would implementing FusedFuture for IfWatch help?

[dvc94ch]

looks like there is no consensus on infinite streams [0].

• [0] Support infinite streams rust-lang/futures-rs#1857

[arkpar]

Was going to open a PR for this myself for a different reason. That boxing that is is done on each poll is the top source for temporary allocations when running substrate/polkadot. Good to see it removed.

[romanb]

well, that is what I did initially. one thing I don't like about that is that it has to return an Option and every caller needs to handle the None case that never happens. would implementing FusedFuture for IfWatch help?

I agree that having to handle an "impossible" None case is annoying, though conceptually Stream still seems to be the right abstraction, since IfWatcher provides a stream of events. I guess a FusedFuture is ok as well, at least there seems to be prior art for a FusedFuture for a Stream that can be polled repeatedly 🤷‍♂️.